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Revisions 



Version 3.0 

Version 3.0 of this specification is the third release of the international Multi-Drop Bus / 
Internal Communication Protocol (MDB / ICP). This specification is the continued 
effort put forth by technical members of NAMA and the EVA. The basis for this 
specification is the Version 2.0 international Multi-Drop Bus / Internal Communication 
Protocol (MDB / ICP) released on October 4, 2002. 

Of special note are the four major changes that were made to the specification: 

• Added a second Cashless Device peripheral address in Section 7 

• Replaced the Audit Unit with the Communications Gateway in Section 8 

• Added the Coin Hopper or Tube - Dispenser in Section 1 (new) 

• Assigned 2 addresses to be used for experimental peripherals 

The following lists the primary revisions to the Version 3.0 of the MDB / ICP. 

Section 1 - General Information 
Section 1 .3 

• Changed the Level and Options chart for the Communications Gateway and 
the Coin Hopper or Tube- Dispenser 

Section 2- Communication Format 
Section 2.2 

• Added headers for the Response Codes 

• Clarified non response processing for Master-to-Peripheral and Peripheral- 
to-Master communication. 

Section 2.3 

• Updated the Peripheral Address table for the Communications Gateway, 
Coin Hopper, Cashless Payment 1 , and Experimental addresses 

• Defined the use of the experimental addresses 

Section 2.5 

• Added new RESET examples F & G. 
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Section 5 - Coin Acceptor / Changer 
Section 5.2 

• Renamed the STATUS command to SETUP command 

• Added a new Possible Credited Coin Removal status code (ODh) 

Section 6- Bill Validator 
Section 6.2 

• Renamed the STATUS command to SETUP command 

• Added a new Possible Credited Bill Removal status code (OCh) 

Section 7 - Cashless Device(s) (New Cashless Device #2) 

Changed name from Cashless Payment to Cashless Device 
Section 7.1 

• Added information regarding the dual addresses for two Cashless Device 
peripherals (1 Oh and 60h) 

Section 7.3 

• Updated Command & Response table for dual addresses 
Section 7.4 

• Updated Command/Response Formats for dual addresses 

Section 8 - Communications Gateway (New Peripheral) 

Sections 8.1 through 8.6 

• Replaced former Audit Unit sections with new Communications Gateway 
Sections 

Section 9 -Universal Satellite Device (USDC) 
Section 9.3 

• Updated POLL table with proper number of bytes (FTL portion) 

• Changed "numeric row and column" to "Item Number" 

Section 10- Coin Hopper or Tube- Dispenser (New Peripheral) 

Sections 10.1 through 10.5 

• Added complete new sections 
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Version 2.0 

Version 2.0 of this specification is the second release of the international Multi-Drop 
Bus / Internal Communication Protocol (MDB / ICP). This specification is the 
culmination of effort put forth by technical members of NAMA, the EVMMA, and the 
EVA. The basis for this specification is the Version 1 .0 international Multi-Drop Bus / 
Internal Communication Protocol (MDB / ICP) released on October 14, 1998. 

The following lists the primary revisions to the Version 2.0 of the MDB / ICP 

Introduction 
Foreword 

• Clarified that the Standard is a communication interface 

Section 1 - General Information 
Section 1 .1 

• Added 3 rd paragraph noting interface specification vs. system specification 
Section 1 .3 

• Added entire Levels and Options section 

Section 2 -Communication Format 
Section 2.1 

• Changed Mode Bit Master-to-Peripheral text 
Section 2.2 

• Removed "command" from Master-to-Peripheral 4 th paragraph 

• Changed RET description 
Section 2.3 

• Defined address OOOOxxxB (00H) for VMC 

• Provided address information to show hexadecimal format 
Section 2.4 

• Changed format to 2.4.X sub-sections and added 2.4.4 on Levels 
Section 2.5 

• Changed RET description 
Section 2.6 

• Added complete File Transport Layer Section 

Section 3 - Bus Timing 
Section 3.1 

• Added 2 nd sentence to tsetup 

Section 4 - Hardware Specification 
Section 4.3 

• Modified complete section and added AMP as alternate source to Molex 
Section 4.4 

• Added pin numbers to schematic 
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Section 5 - Coin Acceptor / Changer 
Section 5.1 

• Provided additional address information 
Section 5.3 

• Added recommended RESET command sequence 

• Modified STATUS response to indicate Country / Currency Codes 

• Modified County / Currency Code to include ISO 421 7 (Appendix A1 ) 

• Added Note 2 to DISPENSE (ODH) command 

• Added FTL POLLed responses 
Added FTL "b3" option bit 

• Added FTL expansion commands 

• Cosmetic changes to all EXPANSION commands 

Split ALTERNATIVE PAYOUT (0FH-02H) and PAYOUT STATUS (OFH- 
03H) command into two separate commands (cosmetic change only) 
Added text to ALTERNATIVE PAYOUT (0FH-02H) Y1 description 
Added Note 3 to ALTERNATIVE PAYOUT STATUS (0FH-03H) 
Section 5.5 

Added "See Note 2 ..."text 

• Added "If both peripherals supported" to Note 

Section 6 - Bill Validator 
Section 6.1 

• Provided additional address information 
Section 6.3 

• Added recommended RESET command sequence 

• Modified STATUS response to indicate Country / Currency Codes 

• Modified County / Currency Code to include ISO 421 7 (Appendix A1 ) 

• Added Level 2 information 

• Added Level 2 option bytes w/ new EXPANSION COMMANDS: 

37H 01 H Level 2 Option Bit Enable 
37H 02H Level 2 Identification 

• Added FTL POLLed responses 
Added FTL "bO" option bit 

• Added FTL expansion commands 

• Modified last sentence in SECURITY command to link to Z9-Z10 
STATUS response 

• Cosmetic changes to all EXPANSION commands 

Section 6.5 

• Added "If both peripherals supported" to Note 
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Section 7 - Cashless Payment 
Section 7.2 & 7.2.7 

• Added Level 03 Negative Vend Request 
Section 7.2.2 

• Changed 1 st sentence to link Setup to 7.4.1 information 
Section 7.2.4 

• Added Negative Vend and Revalue 
Section 7.2.7 

• Added Level 03 Negative Vend Request 
Section 7.3 

• Added bold text regarding defining currency at the beginning of a session 

• Broke uninterruptable table into VMC Command and Reader Response 

• Added Level 03 NEGATIVE VEND REQUEST to VMC Command table 

• Added Level 03 DATA ENTRY REQUEST to Reader Response table 

• Highlighted command out of sequence hard resets from VMC 

• Moved Vend Failure Sequence to 7.4.8 
Section 7.3 -Table 1 

• Changed name to COMMANDS & RESPONSES 

• Changed Comment column to VMC / Reader Level Support 

• Linked all commands and responses to Levels 
Added DATA ENTRY REQUEST POLLed responses 

• Added FTL POLLed responses 

• Added FTL commands 

Added NEGATIVE VEND REQUEST responses 
Defined 1 4H-1 AH and 20H-FEH as "For Future Use" 
Section 7.4.1 

• Cosmetically modified RESET command sequence 
Added 32 bit SETUP MAX/MIN PRICE 

• Changed text following Reader response 
Section 7.4.2 

• Clarified Level 01 information (reader has no revalue capability) 

• Added Level 03 information 

• Modified SETUP response to indicate Country / Currency Codes 

• Modified County / Currency Code to include ISO 421 7 (Appendix A1 ) 

• Added bold Note in Z3 -Z4 County / Currency Code 

• Added definition for Miscellaneous Options "b4- b7" 
Section 7.4.3 

• Added Level 03 SETUP if Expanded Currency Mode 
Section 7.4.4 

• Added Level 03 BEGIN SESSION response if Expanded Currency Mode 

• Added Level 03 VEND APPROVED response if Expanded Currency Mode 

• Added Level 03 PERIPHERAL ID response if Expanded Currency Mode 
Clarified COMMAND OUT OF SEQUENCE definition 
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• Added Level 03 REVALUE LIMIT AMOUNT response if Expanded Currency 
Mode 

• Added Level 03 DATA ENTRY REQUEST response if Data Entry Mode 

• Added Level 03 DATA ENTRY CANCEL response if Data Entry Mode 

• Added Level 03 FTL REQ TO RCV response if FTL Mode 
Added Level 03 FTL RETRY / DENY response if FTL Mode 
Added Level 03 FTL SEND BLOCK response if FTL Mode 

• Added Level 03 FTL OK TO SEND response if FTL Mode 

• Added Level 03 FTL REQ TO SEND response if FTL Mode 
Section 7.4.5 

• Added Level 03 VEND command if Expanded Currency Mode 

• Added Level 03 VEND APPROVED response if Expanded Currency Mode 
Section 7.4.8 

• Added Vend Failure (from 7.3) 
Section 7.4.10 

• Added Level 03 VEND command if Expanded Currency Mode 
Section 7.4.11 (new) 

• Added complete Level 03 NEGATIVE VEND Request section 
Section 7.4.15 (new) 

• Added complete Level 03 DATA ENTRY Request section 
Section 7.4.16 

• Added Level 03 REVALUE Request command if Expanded Currency Mode 
Section 7.4.17 

• Added Level 03 REVALUE Limit Request command if Expanded Currency 
Mode 

Section 7.4.18 

• Added Level 03 EXPANSION REQUEST ID response if Expanded 
Currency Mode 

Section 7.4.22 

Added Level 03 EXPANSION ENABLE OPTIONS command 
Section 7.4.23 

• Added Level 03 FTL REQ TO RCV command & responses if FTL Mode 
Section 7.4.24 

Added Level 03 FTL RETRY / DENY command if FTL Mode 
Section 7.4.25 

• Added Level 03 FTL SEND BLOCK command & response if FTL Mode 
Section 7.4.26 

Added Level 03 FTL OK TO SEND command if FTL Mode 
Section 7.4.27 

• Added Level 03 FTL REQ TO SEND command & responses if FTL Mode 
Section 7.7 

• Added Example Vend Session #1 (Single Negative Vend) 
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Section 8 - Audit Device 
Section 8.1 

• Provided additional address information 
Section 8.3 

• Added FTL POLLed responses 
Added FTL "b3" option bit 

• Added FTL expansion commands 

Section 9 - Universal Satellite Device 
Section 9.1 

• Provided additional address information 
Section 9.3 

• Added FTL POLLed responses 
Added FTL "b2" option bit 

• Added FTL expansion commands 
Document Revision History 

• Deleted 

Appendix 1 - Currency Codes 

• Added entire section (based on ISO 4217) 

Appendix 2 - Battery Operated Card Reader 

• Added entire section 



Version 1 .0 

Version 1 .0 of this specification is the first release of the international Multi-Drop Bus / 
Internal Communication Protocol (MDB / ICP). This specification is the culmination 
of effort put forth by technical members of NAMA, the EVMMA, and the EVA. The basis 
for this specification is the International Multi-Drop Bus Interface Standard published 
by NAMA and the Internal Communication Protocol published by the EVMMA. The 
NAMA document was originally introduced on October 19, 1993 and later revised on 
August 1 9, 1 994, June 20, 1 997, and October 1 5, 1 997. The EVMMA document was 
adopted in 1 994 and later revised in 1 995. 

The following lists the primary revisions to the original two documents which were 
"combined" to create Version 1 .0 of the MDB / ICP. In actuality, the NAMA MDB was 
the basis of the MDB / ICP with the exception of Section 7 which came from the 
EVMMA ICP. Besides typographical corrections and actual feature changes (below), 
the entire document was edited to provide a more uniform appearance. 

The following lists the primary revisions to the Version 1 .0 of the MDB / ICP. 
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Hardware Specification - Section 4.3 

• Added drawings of the MDB male and female connectors. 

Coin Acceptor / Changer - Section 5.3 

• Added Expansion commands: 

OF-05 Send Current Diagnostic Status 
OF-06 Send Controlled Manual Fill Report 
OF-07 Send Controlled Manual Payout Report 

Coin Acceptor / Changer - Section 5.5 

• Added coin acceptance and coin payout power requirements for coin 
changers using motorized payout mechanisms. 

• Added note about simultaneously supplying bill validator transport power. 

Bill Validator - Section 6.5 

• Added note about simultaneously supplying coin mechanism coin 
acceptance power. 

Cashless Payment - Section 7.2.6 

• Added Level 02 Revalue capability. 

Cashless Payment - Section 7.3 

Added Level 02 REVALUE REQUEST. 

• Removed NAK (NCK) response from uninterruptable state and 
unexecutable command descriptions. 

• Eliminated the BUSY response to vend failure sequences. 

• Modified Table 1 per above. 

Cashless Payment - Section 7.4.1 

• Further defined the initializing sequence following a RESET command. 

Cashless Payment - Section 7.4.2 

• Further defined the Z7 Application Maximum Response Time. 

• Added Z8 - b3 for supporting the VEND/CASH SALE subcommand. 

Cashless Payment - Section 7.4.4 

• Begin Session (03h) - Added Level 02 Reader Z4-Z1 data. 

• Malfunction/Error (OAh) - Added error code 1 1 00 (refund error). 

• Command Out of Sequence (OBh) - Added Z2 data. 

• Eliminated Busy (OCh) response. 

• Added Level 02 Reader Revalue Approved (ODh) response. 

• Added Level 02 Reader Revalue Denied (OEh) response. 

• Added Level 02 Reader Revalue Limit Amount (OFh) response. 

• Added Level 02 Reader User File Data (1 Oh) response. 
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• Added Level 02 Reader Time/Date Request (1 1 h) response. 

Cashless Payment - Section 7.4.10 

• Added Level 01 Reader CASH SALE (1 3h/05h) VMC command. 

Cashless Payment - Section 7.4.14 

• Added Level 02 Reader Revalue- Request (15h/00h) VMC command. 

Cashless Payment - Section 7.4.15 

• Added Level 02 Reader Revalue- Limit Request (1 5h/01 h) VMC command. 

Cashless Payment - Section 7.4.17 

• Obsoleted EXPANSION - Read User File (1 7h/01 h) VMC command. 

Cashless Payment - Section 7.4.18 

Obsoleted EXPANSION - Write User File (1 7h/02h) VMC command. 

Cashless Payment - Section 7.4.19 

• Added Level 02 Reader Write Time/Date File (1 7IY03h) VMC command. 

Cashless Payment - Section 7.5 

• Further defined the non-response time with the "Application Maximum 
Response Time" Z7. 

Cashless Payment - Section 7.6 (original ICP Spec) 

• Moved this section (ICP Payment Media Return Button) to Section 73.2. 

Cashless Payment - Section 7.6 (MDB/ICP Spec) 

• Previously was the ICP 7.7 with no modifications. 
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Introduction 



Foreword 



This voluntary Standard contains basic requirements for a vending machine 
communication interface within the limitations given below and in the General 
Information section of this Standard. These requirements are based on sound 
engineering principles, research, field experience, and an appreciation of the problems 
of manufacture, installation, and use derived from consultation with and information 
obtained from manufacturers, users, and others having specialized experience. These 
requirements are subject to revision as further experience and investigation may show it 
necessary or desired. 

NAMA, in performing its functions in accordance with its objectives, does not assume or 
undertake to discharge any responsibility of the manufacturer or any other party. The 
opinions and findings of NAMA represent its professional judgment given with due 
consideration to the necessary limitations of practical operation and state of the art at 
the time the NAMA Standard is processed. NAMA shall not be responsible to anyone 
for use or reliance upon Standard by anyone. NAMA shall not incur any obligation or 
liability for damages, including consequential damages, arising out of or in connection 
with the use, interpretation of, reliance upon this Standard. 



Standard Review 



A complete review of this standard shall be conducted at least every five years to keep 
requirements consistent with technology. These reviews shall be conducted by 
representatives from industry and user groups on the NAMA Vending Technology 
Standards Committee at that time. 
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Section 1 

General Information 



1.1 Introduction 



This document defines a serial bus interface for electronically controlled vending 
machines. The interface is a 9600 baud Master-Slave arrangement where all 
peripherals are Slaves to a Master controller. 

The intent of this document is to standardize vending machines that employ electronic 
control (traditionally known as vending mechanism controller - VMC) so that all vending 
and peripheral equipment communicates identically. 

It should be noted that this document is a vending machine interface / protocol 
specification and not a vending machine system specification. Each machine 

manufacturer should provide a specification on the overall operation of the machine. 
1.2 Operational and Application Notes 



The serial bus, or Multi-Drop Bus (MDB) is configured for Master-Slave operation. 
There is one Master with capability of communicating with up to thirty-two peripherals. 
The Master is defined as the Vending Machine Controller (VMC). 

Each peripheral is assigned a unique address and command set. The master will "poll" 
the Bus for peripheral activity. That is, each peripheral is asked for activity, and 
responds with either an acknowledge, negative acknowledgment, or specific data 
dependent on its current activity. If a peripheral does not respond within a predefined 
time, (t-non-response as defined in the peripheral sections) it is assumed that it is not 
present on the Bus. 

Bus interference, or "crashes" are prevented because each peripheral only responds 
upon being polled. Since there is only one master, and all communication is initiated by 
the Master, Bus "crashes" are easily precluded. 

All peripherals will recognize a disable command, or commands, sent by the Master. 
This allows for disabling of individual peripherals for various reasons, for example, 
power management techniques. 

Error checking and correction is accomplished by using checksums (CHK) and a 
retransmit command. 
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1.3 Levels and Options 

Since the introduction of the earliest Multi-Drop Bus specification, functional levels and 
operational options have been established for most of the peripherals on the MDB/ICP 
interface. These have provided the capability for new features to be implemented as 
new requirements and features were needed for the international vending industry. 

1.3.1 Levels 

Levels of peripheral functionality were established when a major change occurred in the 
peripheral that added extended commands and responses. Due to potential conflicts 
between a VMC level and a peripheral level, neither the VMC nor the peripheral should 
issue a command or reply with a response that is not supported by the other device. 

The VMC must initially determine (via the appropriate STATUS or SETUP command) 
the level of a peripheral before determining which commands it can issue to that device. 
A VMC must only send commands that are supported by the peripheral. For 

example, a Level 3 command may only be issued to a Level 3 or higher peripheral and 
must not be issued to a Level 1 or 2 peripheral. 

The Cashless Payment and the Universal Satellite Device can also learn the respective 
level of the VMC for that device. This information is sent via the SETUP command. It 
is the responsibility of the peripheral to only send responses that are supported 
by the VMC. For example, a Level 3 response may only be sent to a Level 3 or higher 
VMC and must not be sent to a Level 1 or 2 VMC. Effectively, the VMC and peripheral 
should support the highest common level. 

For total compatibility, VMCs and peripherals should support all lower levels. For new 
designs after July 2000, it is strongly recommended that VMCs and peripherals 
must support all lower levels. Commercial or regional issues may cause machine or 
peripheral manufacturers to implement only specific levels; however, this is a decision 
(and risk) made by the machine or peripheral manufacturer. 

1.3.2 Options 

Options were established in the peripherals to provide various additional operational 
features that may be required for specific vending applications. As the name implies, 
these features are "above and beyond" the standard core of required functionality. 

At power on and after a Bus Reset or a RESET command, all options are disabled. 
During the initialization command sequences, the VMC determines the optional 
features supported by the peripherals. The VMC will then enable the features it is 
going to use. Until the feature is enabled, it is the responsibility of the peripheral to 
ignore feature specific commands and not respond with feature specific responses. 
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1.3.3 Currently Established Levels and Options 

The following table provides a brief description of each of the currently established 
levels and options of the various MDB/ICP peripherals. Please refer to the specific 
sections for each device for more detailed information. 



D a h i r* h a t*£i 1 c 
nciipilcicila 


1 1 o 


Hntinnc 


ucaunpiiun 


Coin Changer 


1 


n/a 


Never released 




2 


none 


Supports standard commands 




3 


below 


Supports Expansion ID command and optionally 
supports commands for features below 






DU 


Alternative rayout ivietnoo 






D\ 


txtenaeo uiagnostics 






b2 


Controlled Manual Fill and Payout 






b3 


File Transport Layer (FTL) 










Bill Validator 


1 


none 


Supports standard commands and Expansion ID 
command without options 




2 


below 


Supports expansion ID command with options 
and optionally supports commands for features 
below 






bO 


File Transport Layer (FTL) 






Cashless 
Device #1 & #2 


1 


below 


Supports standard commands and Expansion ID 
command. Readers do not have revaluation 
capability 






bO* 


Reader is capable of restoring funds to card 






b1* 


Reader is multivend capable 






b2* 


Reader has a display available 






b3* 


Reader supports VEND-CASH SALE command 








*bits in the SETUP-Config command 




2 


above 


Supports Revalue, Time/Date, Read User File 
(obsolete), and Write User File (obsolete) 
commands 
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Peripherals 


Levels 


Options 


Description 


Cashless 
Device #1 & #2 

(continued) 


3 


above 
& 

below 


Supports expansion ID command with options 
and optionally supports commands for features 
below (bits in the Level 3 Expansion ID 
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b4** 


Data Entry 








**bits in the Level 3 Expansion ID command 










Communications 


1 


none 


Obsolete (former Audit Unit) 


Gateway 


2 


none 


Obsolete (former Audit Unit) 




3 


below 


Supports Expansion ID command and 
optionally supports commands for features 
below 






bO 


File Transport Layer (FTL) 






b1 


Verbose Mode 










Universal 
Satellite Device 


1 


below 


Supports all basic commands and optionally 
supports commands for features below 


(USD) 




bO 


USD is capable of storing and controlling 
pricing 






b1 


USD is capable of selecting items to vend 






b2 


File Transport Layer (FTL) 






Coin Hopper or 
Tube - Dispenser 


1 


below 


Supports Expansion ID command and 
optionally supports commands for features 
below 






bO 


File Transport Layer (FTL) 
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Section 2 

Communication Format 



2.1 Byte Format 



Baud Rate: 9600 NRZ 

Serial Bit Format: 1 Start Bit 

8 Data Bits 
1 Mode Bit 

I Stop Bit 

I I Bits Total 

LSB MSB 
Start 1 2 3 4 5 6 7 Mode Stop 

Mode Bit: Master-to-Peripheral 

The mode bit differentiates between ADDRESS bytes and DATA bytes. ADDRESS 
bytes must be read by all peripherals, DATA bytes are only read by the peripheral that 
has been addressed. 

The mode bit is set (logic one) to indicate an ADDRESS byte, and not set (logic zero) to 
indicate a DATA byte. 

Mode Bit: Peripheral-to-Master 

The mode bit must be set on the last byte sent when data is sent from a Slave to the 
Master. 
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2.2 Block Format 



Master-to-Peripheral 

A Communication Block for Master-to-Slave transmissions is defined as an Address 
byte, optional data bytes, and a CHK byte. A block is limited to a maximum of thirty-six 
(36) bytes. 

The upper five bits (MSB) of the Address Byte will be used for addressing. That is, bits 
7,6,5,4,3 of the previous byte description will be used for addressing. 

The lower three bits (i.e. 2,1 ,0) of the Address Byte will contain peripheral specific 
commands. This will allow up to eight instructions to be embedded in the first byte of a 
block. 

The VMC Master will respond to data from a peripheral with an Acknowledgment (ACK), 
Negative Acknowledgment (NAK), or Retransmit (RET). These are defined later in the 
document. The 5 mS time-out (t-response) described in the Bus Timing section of this 
document is the equivalent of a NAK. 

If the addressed Slave does not respond within the 5 mS time-out (silence), the Master 
may repeat the same command, or send a different command, until it receives an 
answer or until the end of the Non-Response time, as defined in the peripheral sections. 
See Example in 2.5D. The RESET command should not be used as a recovery method 
to a 5 mS time-out (t-response) until after exceeding the Non-response time. The VMC 
may send commands to any other peripheral during this time. 

Peripheral-to-Master 

A Communication Block for Slave-to -Master transmissions consists of either a data 
block and a CHK byte, a acknowledgment (ACK), or a negative acknowledgment (NAK). 

The 5 mS time-out (t-response) described in the Bus Timing section of this document is 
the equivalent of a NAK command. In addition, it is recommended that the peripheral 
use this time-out as the NAK when a reception error of the ADDRESS byte occurs. This 
will prevent several peripherals from trying to simultaneously respond with a NAK. 

A data block consists of one or more data bytes followed by a CHK byte. The CHK byte 
is defined later in this document. 

The data block and CHK byte are limited to a maximum size of 36 bytes. 

A CHK byte is not required when a peripheral responds with NAK or ACK byte. ACK 
and NAK are defined later in this document. 
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The peripheral must set the mode bit on the last byte sent to signify end of transmission. 
This will be either the CHK byte of a block, a NAK byte, or an ACK byte. The mode bit 
must not be set except for the conditions above. 

A peripheral response of ACK or NAK signifies the end of the exchange. 



When a peripheral responds with a data block, the VMC must respond with an ACK, 
NAK or RET. If the Master cannot respond within the 5 mS time-out (t-response) the 
peripheral must repeat the data block, or append it, at the next possible occasion (i.e. 
a later POLL). The same behavior is to apply when the Master responds with NAK. 



to 



CHK Byte 

A CHK byte must be sent at the end of each block of data. The CHK byte is a 
checksum calculated by adding the ADDRESS byte and all DATA bytes. The CHK byte 
is not included in the summation. The carry bit for CHK additions is ignored since the 
CHK byte is limited to eight bits. 

The following example shows a CHK byte calculation for a possible response to a 
STATUS command sent to a USA changer slave. See section 5 for details of byte 
meanings. 

02H Changer feature level 

00H Country code for USA 

01 H Country code for USA 

05H Coin scaling factor 

02H Decimal place 

00H Coin type routing 

07H Coin type routing 

01 H Coin type has value of 1 scaling factor 

02H Coin type 1 has value of 2 scaling factor 

05H Coin type 2 has value of 5 scaling factor 

1 4H Coin type 3 has value of 20 scaling factor 

FFH Coin type 4 is a token 

1 2CH Therefore the CHK byte would be equal to 2CH 

A checksum will be performed on all full blocks of communication. A checksum will not 
be performed on ACK, NAK, or RET bytes. 
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Response Codes 

The following codes are reserved for the ACK, NAK and RET bytes: 

ACK 00H (acknowledgment/checksum correct) 

RET AAH (Retransmit the previously sent data. 

Only the VMC can transmit this byte) 

NAK FFH (Negative acknowledge) 

The VMC and peripheral must also recognize the 5 
mS time-out (t-response) as a NAK. 

NOTE: To improve system reliability it is recommended that when receiving ACK, 
NAK, or RET the receiving device counts the number of bits set in the 
byte. This method will require at least two bit errors in the byte before the 
byte can be mis-interpreted. 

Bus Reset 

The VMC may reset all peripherals by pulling the transmit line "active" for a minimum of 
100 mS. This informs all peripherals to abort any activity and return to its power-on 
reset state. Details of this state for each peripheral are provided in later sections of this 
document. It is recommended that the VMC re-initialize each peripheral after this type 
of reset. 
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2.3 Peripheral Addresses 



The addresses below are defined. Note again that the bits shown are the upper five bits 
(7,6,5,4,3) of the Address Byte and will be used for all addressing including the File 
Transport Layer described in Section 2.6. The lower three bits (2,1 ,0) are used for the 
command. 



Address 



Definition 



OOOOOxxxB 
00001 xxxB 
OOOIOxxxB 
00011xxxB 
00100xxxB 
00101xxxB 
00110xxxB 
00111xxxB 
OlOOOxxxB 
01001xxxB 
01010xxxB 
01011xxxB 
01100xxxB 
01101xxxB 



(OOH) 
(08H) 
(10H) 
(18H) 
(20H) 
(28H) 
(30H) 
(38H) 
(40H) 
(48H) 
(50H) 
(58H) 
(60H) 
(68H) 



Reserved for VMC 
Changer 

Cashless Device #1 
Communications Gateway 
Display 

Energy Management System 
Bill Validator 

Reserved for Future Standard Peripheral 
Universal Satellite Device #1 
Universal Satellite Device #2 
Universal Satellite Device #3 
Coin Hopper or Tube - Dispenser 
Cashless Device #2 

Reserved for Future Standard Peripherals 



11011xxxB (D8H) 

11100xxxB (EOH) 

11101xxxB (E8H) 

11110xxxB (FOH) 

11111xxxB (F8H) 



Reserved for Future Standard Peripherals 
Experimental Peripheral #1 
Experimental Peripheral #2 
Vending Machine Specific Peripheral #1 
Vending Machine Specific Peripheral #2 
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Experimental Peripheral Addresses 

Experimental Peripheral addresses 1 1 "IOOxxxB (EOH) and 1 1 101xxxB (E8H) are 
reserved for use by manufacturers when designing and field testing potential new 
MDB/ICP devices. These addresses are temporary and once the new device is 
approved by NAMA and the EVA, the device will be assigned a different permanent 
peripheral address. Use of the Experimental Peripheral addresses shall be limited to "in 
house" testing and "closed site" field trials. Manufacturers must understand that any 
devices in the field with Experimental Peripheral addresses must be recalled or updated 
to the permanent address if the device is approved by NAMA and the EVA. If not 
approved by NAMA and the EVA, the devices must be recalled or have their addresses 
changed to the Vending Machine Specific peripheral addresses described below. 



Vending Machine Specific Peripheral Addresses 

Vending Machine Specific peripheral addresses (addresses 1 1 1 10xxxB (FOH) and 
11111 xxxB (F8H)) are reserved for Non-Standard or proprietary applications. These 
devices are allowed a unique set of commands. 

All other peripherals are defined as Standard devices. These peripherals must follow 
the specifications to ensure compatibility between manufacturers. 
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2.4 Software Operational Rules 



2.4.1 Power Budget 

The VMC must regulate the power budget. That is, peripherals must be enabled and 
disabled dependent on power availability. The power bus is defined later in this 
document. 

2.4.2 Bytes 

During multi-byte messages the most significant byte is sent first. 

Any bytes within a command or response that are not specifically defined 
should be left in a state. For Level 03 or lower coin mechanisms, Level 
01 bill validators, and Level 01 card readers, this is not a requirement but 
a suggestion. 

2.4.3 Polling 

The following are recommendations for the methods of VMC to peripheral software 
operation. 

Each peripheral should be polled every 25-200 milliseconds. This can be done by 
the POLL command or any other appropriate command. 

If a peripheral has not responded to a poll for its maximum Non- Response time, 
the VMC should continue to poll the peripheral at least every ten seconds with a 
RESET command. (See Example G in Section 2.5). 

2.4.4 Levels 

Due to potential conflicts between a VMC level and a peripheral level, neither the VMC 
nor the peripheral should issue a command or reply with a response that is not 
supported by the other device. 

The VMC must initially determine (via the appropriate STATUS or SETUP command) 
the level of a peripheral before determining which commands it can issue to that device. 
A VMC must only send commands that are supported by the peripheral. For 

example, a Level 3 command may only be issued to a Level 3 or higher peripheral and 
must not be issued to a Level 1 or 2 peripheral. 

The Cashless Payment and the Universal Satellite Device can also learn the respective 
level of the VMC for that device. This information is sent via the SETUP command. It 
is the responsibility of the peripheral to only send responses that are supported 
by the VMC. For example, a Level 3 response may only be sent to a Level 3 or higher 
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VMC and must not be sent to a Level 1 or 2 VMC. Effectively, the VMC and peripheral 
should support the highest common level. 

For total compatibility, VMCs and peripherals should support all lower levels. For new 
designs after July 2000, it is strongly recommended that VMCs and peripherals 
must support all lower levels. Commercial or regional issues may cause machine or 
peripheral manufacturers to implement only specific levels; however, this is a decision 
(and risk) made by the machine or peripheral manufacturer. 

2.5 Typical Session Examples 

A. The diagram below represents a typical transmission when a peripheral is idle. 
VMC: 



ADD* CHK 
Peripheral: 

ACK* 

B. The diagram below represents a typical transmission when a peripheral has data 
to return. 

VMC: 



ADD* CHK ACK 

Peripheral: 



DAT DAT CHK* 

C. The diagram below represents a typical transmission when the VMC has data to 
send. 

VMC: 



ADD* DAT DAT CHK 

Peripheral: 

"ack* 

indicates mode bit set 
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D. The diagram below represents a typical transmission when the VMC determines 
a CHK is not correct. The VMC will respond one of two ways: 

Send a NAK to the peripheral to indicate that the information was not received 
correctly then perform other tasks. Note: When the Master answers with NAK (or 
silence which is treated equally) the slave has to repeat the response, in order to 
ensure the execution of the response (i.e. coin reception etc.). 

OR 

The VMC may send a retransmit (RET) command alerting the peripheral to 
retransmit the previously sent data. 

VMC: 



ADD* DAT CHK RET ACK 

Peripheral: 



DAT DAT CHK* DAT DAT CHK* 

indicates mode bit set. 

E. This diagram represents a situation where the peripheral does not respond within 
the 5 mS time-out (t-response). 

VMC: 



ADD* CHK ADD* CHK 

Peripheral: 



[silence...] ACK* 
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This diagram represents a situation where the peripheral does not respond to a 
command and after its maximum Non-Response time, is reset by the controller. 



Controller 



Peripheral 



Comment 



Command X 
Command Y 
Command Y 
Command Y 



<r Response 

<- [silence...] 

<- [silence...] 

<- [silence...] 



Normal response 
No response 
No response 
No response 



Peripheral does not response 
within its allocated Non- 
Response Time. 



RESET 
RESET 
POLL 
ACK 



<- [silence...] 

<- ACK 

<r JUST RESET 



Software Reset 

Peripheral in initialization routine 



Peripheral operational again 



Peripheral indicates finished 
RESET processing 



Peripheral initialization 
sequence is performed as 
recommended in each 
peripheral section. 
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G. This diagram represents a situation where the peripheral is disconnected or goes 
offline. The controller should send a RESET command every 1 seconds to 
determine if, and when, the peripheral becomes active again. 



Controller 



Peripheral 



Comment 



Command X 
Command Y 
Command Y 
Command Y 



RESET 
RESET 

RESET 

RESET 

RESET 



Response 
[silence...] 
[silence...] 
[silence...] 



<- [silence...] 
<- [silence...] 



<- [silence...] 



[silence...] 



[silence...] 



Normal response 
No response 
No response 
No response 



Peripheral does not response 
within its allocated Non- 
Response Time. 



Software Reset 
Peripheral offline 

Software Reset 
Peripheral offline 

Wait 10 seconds 

Peripheral offline 

Wait 10 seconds 

Peripheral offline 

Wait 10 seconds 

Peripheral offline 
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2.6 File Transport Layer 



The File Transport Layer (FTL) provides a method to send and/or receive high level 
information between peripherals or between a peripheral and the VMC. It is not 
intended to be used for standard vending credit and control functions. An example 
would be loading new validation parameters into a coin changer or bill validator. 

Since the MDB/ICP interface is "driven" by the VMC, it has to be a network manager for 
all FTL data transfers. It acts as a temporary mailbox and data switch for FTL blocks; 
however, the information that is sent via FTL does not have to be interpreted by the 
VMC. The VMC simply uses the destination and source address information provided 
in the MDB/ICP command and response structure to forward the data to the proper 
recipient. 

2.6.1 FTL Process Overview 

If a peripheral needs to transfer data to another peripheral (or the VMC): 

• The VMC must poll the peripheral, 

• The peripheral must answer with a "REQUEST TO SEND", 

• The VMC must get approval to forward data (if necessary), 

• The VMC requests the first data block, 

• The VMC ACKs the first block and forwards to destination, 

• The process repeats until all blocks are sent. 

If the VMC needs to transfer data to a peripheral: 

• The VMC must send a "REQUEST TO SEND", 

• The peripheral approves or denies the transfer request, 

• If approved, the VMC sends the first data block, 

• The peripheral ACKs the first data block, 

• The process repeats until all blocks are sent. 

If a peripheral (A) needs to request a transfer of data from another peripheral (B): 

• The VMC must poll the peripheral A, 

• Peripheral A must send a "REQUEST TO RECEIVE", 

• The VMC forwards the request to peripheral B, 

• Peripheral B decides to honor the request or not, 

• If approved, peripheral B sends the first data block, 

• The VMC forwards the data block to peripheral A, 

• The process repeats until all blocks are sent. 



2.6.2 FTL Detailed VMC Operation 
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The VMC must act as a network manager, it is responsible for checking peripheral 
status and managing network resources as described below, it must: 

• Be aware of which peripherals are active and support the FTL. If a file transfer is 
requested involving a peripheral that does not support it, the VMC should deny the 
transfer using RETRY/DENY defined later. 

• Poll peripherals to become aware that a data transfer is requested. 

• Read data blocks from selected peripherals. 

• If VMC receives a NAK, it should attempt to finish current command/response up to 
5 times. After that, it should abort file transfer as defined by the protocol. 

• Send data blocks to destination device, if not the VMC itself. 

• Repeat these steps for all data blocks, as needed. 

2.6.3 FTL General Operation 

• The FTL "session" would transfer a "file" using several "blocks". The "Dest" and 
"Src" are switched by the VMC directing each block to its destination. 

• All responses can be sent immediately after receipt of command or the command 
can be ACK'ed and the response sent in a delayed fashion (meeting all appropriate 
time-outs). However, FTL responses must NOT be combined with responses to any 
other commands, at any time. 

• File transfers less than 256 blocks are terminated by sending an empty data file 
(SEND BLOCK with no data). File transfers of exactly 256 blocks are terminated by 
block #FE followed by block #FF. 

• It is recommended that files larger than one block: 

1 ) Include a CRC in their data. The transport layer is not responsible for 
checking for correct CRCs. 

2) Include a time out mechanism to prevent system dead locks. The transport 
layer is not responsible for checking for dead locked file transfers. 

• To prevent a system dead lock, the VMC must poll other peripherals during all data 
transfers and service them accordingly. 

• Since the VMC is not knowledgeable about the contents of the file transfer it should 
not disable any peripherals due to a transfer request. This will be the responsibility of 
the peripherals themselves. They may internally disable and report so to the VMC if 
possible, or they may just stop responding to the VMC until ready. The latter may 
cause the VMC to try to reset the peripheral. 

2.6.4 FTL Command and Response Sets For All Components 

The table below defines the VMC commands and peripheral responses that occur 
during an FTL data transfer. Note that the peripheral responses can either be 
immediate to the VMC's command or delayed and provided to a subsequent POLL. 
Definitions are provided on the following page. 
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Command / 
Response 


VMC 
Cmd 1 


Resp 


Source Data (bytes) 


Destination Response 


REQ TO 
SEND 


oc7/FE 


1F 


Dest (1) 
Src (1) 
File ID (1) 
Length (1) 
Control (1) 


OK TO SEND or 
RETRY/DENY 


OK TO SEND 


cc7/FD 


1E 


Dest (1) 
Src (1) 


SEND BLOCK (repeated 
until whole file is 
transferred) 


SEND BLOCK 


cc7/FC 


1D 


Dest (1) 
Block # (1) 
Data (1 to 31) 


ACK 


RETRY/DENY 


cc7/FB 


1C 


Dest (1) 
Src (1) 
Retry delay (1) 


ACK 


REQ TO RCV 


cc7/FA 


1B 


Dest (1) 
Src (1) 
File ID (1) 
Max Length (1) 
Control (1) 


SEND BLOCK (repeated 
until whole file is 
transferred) or 
RETRY/DENY 



Note 1 : Theoc7 represents the address of the destination device (defined in 
Section 2.3) logically OR'd with a hexadecimal 0x07. 
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Dest 1 byte 

The destination address of the peripheral where the data block (not the whole 
file) is being sent to. All addresses refer to the standard MDB defined peripheral 
addresses as defined in Section 2.3. Note that OOOOOxxx (00H) will be used for 
the VMC. Examples are a changer (08H), audit system (1 8H), bill validator 
(30H), and universal satellite device #2 (48H). 

Src 1 byte 

The source address of the peripheral where the data block (not the whole file) is 
being sent from. All addresses refer to the standard MDB defined peripheral 
addresses as defined in Section 2.3. Note that OOOOOxxx (00H) will be used for 
the VMC. Examples are the same as in the Dest above. 

File ID 1 byte 

The type of information desired. NAMA will maintain a list of standard file ID's 
and a definition of what each file type means. Note that if a device responds with 
a "Retry delay" of FFH it should be interpreted that this device does not support 
the requested function. 

Currently defined file IDs include: 

00H: Manufacture ID information. This file must start with the manufactures 

three character manufactures code, anything after that would be up to the 
manufacture to define. 

01 H: DTS defined file. This file must follow the format defined in the EVA-DTS 
standard. This would include the DXS record as well as all data up to and 
including the DXE record. 

OFH to OFFH: This range of files may be used for Manufacturer Specific 
information. The content and format of these files are left up to the 
manufacturer to define. 

Additional ID proposals must be evaluated by the NAMA MDB/ICP technical 
standard committee. 

(Max) Length 1 byte 

The total number of blocks that will (can) be included in the entire file. This byte 
should be used as a counter to determine the amount of data blocks to be 
transferred. 
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Control 1 byte 

This byte contains information that can be used by the VMC and peripherals to 
determine how the data transfer is conducted. Included controls are: 

bO: Reset after transfer. The receiving peripheral should reset itself after the 
file transfer is complete. 

b1 : End of File. The last block of the current FTL session contains the end of 
this file. If clear (=0), then another FTL session will follow with additional 
blocks. If set (=1), then this is the last (or only) FTL session to be sent. 

b2 - b7: Not used, must be set to 

Block # 1 byte 

The sequential number of this block, within the total file, that is being 
requested/sent. All data blocks must be identified by a block number, counting up 
from (first block) to 255. 



Data Block 1 to 31 byte(s) 

The actual data portion of the block. All data must fit into a 31 byte, or less, 
string. The standard MDB CHK byte will signify the end of block. (Peripherals will 
have to use inter-byte time out when receiving blocks from the VMC.) Knowledge 
of the contents of this data is only required by the source and destination 
devices. 

Retry Delay 1 byte 

A time delay that the sender should wait before trying to re-send the entire data 
file again. If a device is not capable of receiving a file in its current state, this byte 
should represent the number of seconds before it will be ready to receive the 
data. If the device simply refuses to accept the file it must answer with a "Retry 
Never" signified by a 00H retry delay. If the device is not present, block 
synchronization is lost, or other failure mode arises a "Retry Never" should be 
used to abort/deny the current file transfer. 
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File Transport Layer Examples 



Below are examples of data transfers between the VMC and a peripheral or between 
two different peripherals via the VMC. 



Peripheral A VMC Peri 


pheral B Comments 


* REQ TO SEND 

(cc7/FE) 

OK TO SEND * 
(1E) 

*■ ACK 


Request to send 
"n" blocks 


*■ SEND BLOCK 

(cc7/FC) 

ACK 


Repeated "n" times 




Peripheral A VMC Peri 




*■ REQ TO SEND 

(cc7/FE) 

RETRY/00 (1C) * 

* ACK 


Denied 




SUCCESSFUL REQUEST - VMC TO PERIPHERAL A 


* POLL (varies) 
REQ TO RCV * 

(1B) 

*■ ACK 


Request receive "n" 
blocks 


* SEND BLOCK 

(a7/FC) 

ACK * 


Repeated "n" times 




DENIED REQUEST - VMC TO PERIPHERAL A 
Peripheral A VMC Peri 




*■ POLL (varies) 
REQ TO RCV * 

(1B) 

*■ ACK 
* RETRY/00 
(a7/FB) 

ACK 


Request receive "n" 
blocks 

Denied 
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VMC ABORTED TRANSFER - VMC TO PERIPHERAL A 
















REQ TO SEND 


Request to send 






(cc7/FE) 


"n" blocks 


OK TO SEND 








(1E) 












ACK 








SEND BLOCK 








(a7/FC) 


Repeated "n" times 


ACK 












RETRY/00 


Aborted! 






(a7/FB) 




ACK 














VMC Peripheral B 


Comments 






REQ TO SEND 


Request to send 






(a7/FE) 


"n" blocks 


OK TO SEND 








(1E) 












ACK 








SEND BLOCK 








(a7/FC) 




RETRY/00 






Aborted! 


(1C) 












ACK 






SUCCESSFUL TRANSFER - PERIPHERAL A TO VMC 




Peripheral A 






Comments 






POLL (varies) 




REQ TO SEND 






Request to send 


(1F) 






"n" blocks 






ACK 








OK TO SEND 








(cc7/FD) 




SEND BLOCK 






Repeated "n" times 


(1D) 












ACK 
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DENIED TRANSFER - PERIPHERAL A TO VMC 

Peripheral A VMC Peripheral B Comments 



«■ POLL (varies) 
REQ TO SEND * 
(1F) 

*■ ACK 




Request to send 
"n" blocks 



«■ RETRY/00 

(oc7/FB) 



Denied 



ACK 




SUCCESSFUL TRANSFER - PERIPHERAL A TO PERIPHERAL B 

VMC 



«■ POLL (varies) 
REQ TO SEND * 
(1F) 

«■ ACK 



Request to send 
"n" blocks 



REQ TO SEND 
(1 F) (a7/FE) 



ACK 



*■ OK TO SEND 
(1E) 







OK TO SEND 
(cc7/FD) 




SEND BLOCK 






Repeated "n" times 


(1D) 




ACK 





SEND BLOCK 

(a7/FC) 



* ACK 



DENIED TRANSFER - PERIPHERAL A TO PERIPHERAL B 

VMC 

*■ POLL (varies) 




REQ TO SEND 
(1F) 



«■ ACK 



Request to send 
"n" blocks 



REQ TO SEND 
(1F) (cc7/FE) 

ACK 



* RETRY/00 (1C) Denied 



RETRY/00 
(a7/FB) 



ACK 
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SUCCESSFUL REQUEST - PERIPHERAL A TO PERIPHERAL B 
Peripheral A VMC Peripheral B Comments 



REQ TO RCV 
(1B) 



*■ POLL (varies) 
*■ ACK 



Request receive "n" 
blocks 



REQ TO RCV 

(oc7/FA) 



ACK 



*■ SEND BLOCK Repeated "n" times 
(1D) 



ACK 



«■ SEND BLOCK 

(cc7/FC) 



DENIED REQUEST - 


PERIPHERAL A TO PERIPHERAL B 
VMC Peripheral B 




REQ TO RCV 
(1B) 




POLL (varies) 
ACK 




Request receive "n" 
blocks 






REQ TO RCV 

(cc7/FA) 

ACK 


* RETRY/00 (1C) 
-» 


Denied 


ACK 




RETRY/00 
(cc7/FB) 
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PERIPHERAL A TRANSFER TO PERIPHERAL B - ABORTED BY A 
Peripheral A VMC Peripheral B Comments 



REQ TO SEND 
(1F) 



«■ POLL (varies) 
*■ ACK 



Request to send 
"n" blocks 



REQ TO SEND 

(oc7/FE) 



ACK 



«■ OK TO SEND 
(1E) 







OK TO SEND 






(cc7/FD) 


SEND BLOCK 






(1D) 










ACK 



SEND BLOCK 
(a7/FC) 



* ACK 



Repeated "n" times 



RETRY/00 (1C) * 


POLL (varies) 
ACK 




Aborted! 




RETRY/00 








(a7/FB) 










* ACK 
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PERIPHERAL A TRANSFER TO PERIPHERAL B - ABORTED BY B 



Peripheral A 



VMC 



Peripheral B Comments 



REQ TO SEND 
(1F) 



«■ POLL (varies) 
*■ ACK 



Request to send 
"n" blocks 



REQ TO SEND 

(oc7/FE) 



ACK 



«■ OK TO SEND 
(1E) 







OK TO SEND 






(a7/FD) 


SEND BLOCK 






(1D) 










ACK 



SEND BLOCK 

(cc7/FC) 



* ACK 



Repeated "n" times 







POLL 

(varies) REQ 




SEND BLOCK 




BLOCK (cc7/FD) 




(1D) 




ACK 








SEND BLOCK 








(a7/FC) 


*■ RETRY/00 (1C) Aborted! 






ACK 








RETRY/00 




ACK 




(a7/FB) 
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Section 3 



Bus Timing 



3.1 Timing Definitions 



Baud rate 



t 

inter-byte (max.) 
t 

response (max.) 



t 

break (VMC) 



setup 



The rate of bit transfer per second. 

The maximum time allowed between 
bytes in a block transmission. 

The maximum time any device, 
master or peripheral, will take to 
respond to a valid communication. 

The minimum time of the Bus Reset 
signal sent by the VMC to reset all 
peripherals. 

The minimum set-up time before the 
VMC attempts to communicate after 
a reset signal. Peripheral devices may 
choose to not respond for up to the non- 
response time defined in each peripheral 
section. 



3.2 Timing Specifications 



Baud Rate 



t 



inter-byte (max.) 



t 



response (max.) 

t 

break (min.) 

t 

setup (min.) 



= 9600+1%/-2% NRZ 

= 1.0 mS 

= 5.0 mS 

= 100 mS 

= 200 mS 
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NOTE: All peripherals have the option of not responding to the VMC. Non- 
response timing is defined in the peripheral specification. 



3.3 Timing Diagram 



Controller 



DAT J |_C H K: 



BREAK 



SETUP 



ADD* 



PeriDheral 



i_r 



t inter-byte 



" t break 



t response 



- 1 setup 



NOTE: * indicates that the mode bit is set 
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Section 4 

Hardware Specification 



4.1 Bus Power Supply Definition 



The information below defines the minimum VMC voltage output. The actual current 
ratings per peripheral will be defined in their respective sections. 

Power supply filtering is optional, therefore if a peripheral requires more power, or 
tighter regulation, they may elect to supply their own power, or filtering, from available 
sources elsewhere in the machine. 

VMC Voltage Output: 

Minimum = 20 VDC rms. (rectified and optionally 
filtered) 

Nominal = 34 VDC unreg. (rectified and filtered) 
24 VDC rms.(rectified only) 

Maximum = 42.5* VDC(ripple voltage upper limit) 
* High line input may allow 45 VDC 
peak (max.). 



4.2 Bus Transmitter / Receiver Specification 



The following section describes the 5V, optically isolated, current loop system between 
the Master and the Slave. 

VMC Master: 

Transmit: 

Minimum source current (active): 1 00 mA @ 4V 

Maximum leakage current (inactive): 100 uA 

NOTES: 1 ) The transmit line must be able to withstand a short while 
in the active mode. 

2) 1 5 mA should be added for each peripheral over six. 
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Receive: 



Minimum input current (active): 
Maximum input current (inactive): 



15mA@ 1V 
1 mA 



Peripheral Slave: 



Receive: 



Maximum input current (active): 
Maximum input current (inactive): 



15mA@4V 
100 uA 



Transmit: 



Minimum sink current (active): 
Maximum leakage current (inactive): 



15 mA@ 1V 
30 uA 



4.3 Connector Specification 



Connector assemblies supplied by the NAMA approved suppliers, noted in Section 
4.3.6, are intermateable and meet or exceed the minimum requirements identified in 
Sections 4.3.1 , 4.3.2, 4.3.3, 4.3.4, and 4.3.5 when tested in the mated condition. NAMA 
must approve any supplier changes to the fit, form, or function. Discrete components, 
i.e. contacts, are not required to be inter-changeable between supplier products. 



4.3.1. Material 

4.3.1 .1 . Terminal: Phosphor Bronze 

4.3.1 .2. Plating: Tin or Tin/Lead 

4.3.1 .3. Housing: UL 94V-2 nylon 



4.3.2. Ratings 



Section 


Item 


Requirement 


4.3.2.1. 


Rated Voltage (Max) 


600 Volts AC 


4.3.2.2. 


Maximum Rated Current (Six Circuit) 


7 Amps 


4.3.2.3. 


Ambient Temperature Range (including terminal T-rise) 


-40°C to +105°C 
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4.3.3. Electrical Performance 



Section 


Item 


Test Condition 


Requirement 


4.3.3.1. 


Contact 
Resistance 


Mate Connectors, measure by dry circuit, 20 
mV max., 10 mA. Wire resistance shall be 
removed from the measured value. 


10 ma Max. 


4.3.3.2. 


Insulation 
Resistance 


Mate Connectors, apply 500V DC between 
adjacent terminal or ground. 


1000 MQ Min. 


4.3.3.3. 


Dielectric 
Strength 


Mate Connectors, apply 1500V AC for 1 
minute between adjacent terminal or ground. 


No Breakdown. 



4.3.4. Mechanical Performance 



Section 


Item 


Test Condition 


Requirement 


4.3.4.1. 


Insertion and 
Withdrawal Force 


Insert and withdraw connectors at a speed rate 
of 25 +/- 3mm / minute. 


Noted Below 




6 Pos Insertion Max. 


6 Pos Withdrawal Min. 




Initial 


30* cycle 


Initial 


30* cycle 




41.2 N 


38.2 N 


2.9 N 


2.4 N 


4.3.4.2. 


Crimping Pull Out 
Force 


Mount the crimped terminal, apply axial force 
on the wire at a rate of 25 +/- 3mm minute. 

16AWG 


88 N Min. 








18AWG 


88 N Min. 








20AWG 


59 N Min. 








22AWG 


39 N Min. 








24AWG 
26AWG 


29 N Min. 
20 N Min. 








28AWG 


10N Min. 


4.3.4.3. 


Terminal Insertion 


Insert the crimped terminal into the housing. 


15 N Max. 




Force 








4.3.4.4. 


Terminal/Housing 
Retention Force 


Apply axial pull out force at the speed rate of 
25 +/- 3mm /minute. 


22 N Min. 


4.3.4.5. 


Locking / 


Measure force to lock & unlock connector 


Lock: 30 N Max. 




Unlocking Force 


housings (without contacts) at a rate of 25 +/- 
3mm / minute. 


Unlock: 50 N Min. 
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4.3.5. Environmental Performance 



Section 


Item 


Test Condition 


Requirement 


4.3.5.1. 


Repeated 
Insertion / 
Withdrawal 


When mated up to 30 cycles 
repeatedly by rate of 10 cycles per 
minute. 


Contact 
Resistance 


20 ma Max. 


4.3.5.2. 


Temperature Rise 


Carrying rated current load. 


30°C Rise Max. 


4.3.5.3. 


Vibration 


Amplitude: 1.5mm P-P 


Appearance 


No Damage 






Sweep Time: 10-55-10 Hz in 1 
minute. 


Contact 
Resistance 


20 ma Max. 






Duration: 2 hours in each X,Y,Z 


Discontinuity 


1 (i sec. 






axis. 




Max. 


4.3.5.4. 


Shock 


50 G; 3 strokes in each X,Y,Z 


Appearance 


No Damage 






axis. 


Contact 
Resistance 


20 ma Max. 








Discontinuity 


1 (i sec Max. 


4.3.5.5. 


Heat Resistance 


105 +/-2°C,96 hours 


Appearance 


No Damage 








Contact 


20 ma Max. 








Resistance 




4.3.5.6. 


Cold Resistance 


-40+/-3°C,96 hours 


Appearance 


No Damage 








Contact 


20 ma Max. 








Resistance 




4.3.5.7. 


Humidity 


Temperature: 60 +/- 2°C 


Appearance 


No Damage 






Relative Humidity: 90% -95% 
Duration: 96 hours 


Contact 
Resistance 


20 ma Max. 








Dielectric 


No 








Strength 


Breakdown 








Insulation 


1000 Ma 








Resistance 


Min. 


4.3.5.8. 


Temperature 


5 Cycles: 


Appearance 


No Damage 




Cycling 


a) -55°C ; 30 Minutes 

b) 105°C ; 30 Minutes 


Contact 
Resistance 


20 ma Max. 


4.3.5.9. 


Salt Spray 


48 +/- 4 hours exposure to salt 


Appearance 


No Damage 






spray from 5 +/- 1% solution at 35 


Contact Res. 


20 ma Max. 






+/-2°C. 






4.3.5.10 


SO2 Gas 


24 hour exposure to 50 +/- 5 ppm 


Appearance 


No Damage 






S0 2 gas at40+/-2°C. 


Contact Res. 


Max. 
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4.3.6 Approved Suppliers and Part Numbers 

4.3.6.1. Suppliers 

Molex: Mini-Fit, J r.™ Product 
AMP: AMP-DUAC™ Product 

4.3.6.2. Peripherals 

Connector: Six (6) Circuit Receptacle Housing 

Molex 39-01-2060 
AMP P/N 106527-6 

Terminals: Female Contacts (sockets), Tin 

Molex 39-00-0065 

AMP P/N 106528-2 or 106529-2 

Strain Relief: The strain relief shall not exceed a Maximum Form Factor of 0.85 inch wide x 
0.75 inch high x 1.90 inch long, excluding integrated hinges and wire ties. 

Molex 15-04-0296 
AMP P/N 1375618-1 

4.3.6.3. Bus Harness 

Connector: Six (6) Circuit Plug Housing 

Molex 39-01-2061 

AMP P/N 794550-6 or 794542-6 

Terminals: Male Contacts (pins), Tin 

Molex 39-00-0067 

AMP P/N 794578-1 or 794576-1 

4.3.6.4. VMC Connector (Direct PCB Mount) 

Vertical Header: Male Contacts (pins), Tin 

Molex 39-28-1063 
AMP P/N 794664-6 

Right Angle Header: Male Contacts (pins), Tin 

Molex 39-30-1060 
AMP P/N 794448-1 
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4.3.6.5. Approved Parts - Alternate Form Factors 

Select applications may require connector configurations with alternate form 
factors. Alternate form factor connectors may be used provided they are: 

• provided by the Approved Suppliers listed 

• part of the Approved Supplier Product Family portfolio 

• intermateable with the approved connector part numbers listed 

• meet the performance objectives set forth in this specification 
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Connector Pin-out: 



Line 1 - 34 VDC 

Line 2 - DC Power Return 

Line 3 - N/C 

Line 4 - Master Receive 

Line 5 - Master Transmit 

Line 6 - Communications Common 





Peripheral Connector 

Face View 
Receptacle 
(Sockets) 



VMC / Bus Connector 

Face View 
Header 
(Pins) 
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4.4 Example Schematic 



VMC 



« 



o VMC Voltage Output 

/2L 



V 



+5VDC 



1 



— VA/V- 



V 



Master 
\ Transmit 



+5 VDC 



CMOS 
Gate 



Master 
Receive 

<<^— 



Communications 
Common 

« 



Peripheral 



Slave 1 



-\ Vv — 
- 



Rev 



Xmit 



Slave 2 



^ Rev 



Xmit 



Slave 3 



^Rcv 



N 



Xmit 
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Section 5 

Coin Acceptor/Changer 

VMC/Peripheral Communication Specifications 

5.1 Introduction 



This section defines the communication bytes sent and received by a coin 
accepting device ("Changer"). As defined in Section 2.3, the changer's address 
is 00001 xxxB (08H). 

Unless stated otherwise, all information is assumed to be in a binary format. 

There are currently two levels of support defined for the coin mechanism 
interface, Level 2 and Level 3. The level of coin mechanism operation is sent to 
the VMC in the response to the STATUS command (defined later in this section). 
The following paragraphs will define how a VMC should differentiate between 
each level. 

Level 2 Changers 

For level 2 changers, VMC operation consists of monitoring inputs from the coin 
mechanism, accumulating credit, issuing a coin acceptance disable command 
when appropriate, and issuing appropriate payout commands based on the VMC 
resident payout algorithms and escrow rules. 

Level 3 Changers 

For level 3 changers, VMC operation is the same as defined above for level 2, 
with the addition of the EXPANSION command and its implications (defined later 
in this section). The VMC has the option of sending the EXPANSION command 
to the coin mechanism to determine the coin mechanism's manufacturer code, 
serial number, model/tuning revision, software version, and optional features. 
Based on the optional feature information the VMC will determine the appropriate 
operating mode (in other words, modes that both the coin mechanism and the 
VMC can support), enable any appropriate coin mechanism features by sending 
an appropriate feature enable command back to the coin mechanism, and enter 
the proper operating mode. This technique allows all VMCs and peripherals to 
accommodate existing feature capabilities and provides a means for upgrading 
Level 3 equipment. 
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5.2 VMC Commands 



Command 

RESET 

SETUP * 



Hex Code Description 

08H Command for changer to self-reset 

09H Request for changer setup information. 



TUBE STATUS OAH 
POLL OBH 
COIN TYPE OCH 



DISPENSE 



EXPANSION 
COMMAND 



ODH 



OFH 



Request for changer tube status. 

Request for changer activity status. 

Signifies coin types accepted and 
allowable coin dispensing. This 
command is followed by setup data. 
See command format section. 

Command to dispense a coin type. 
Followed by coin type to dispense. 
See command format section. 

Command to allow addition of 

features and future enhancements. Changers 

at feature level 2 do not support this command. 



NOTE: An EXPANSION command is always followed by a "sub-command." 
This command allows for feature additions. 



In Version 1 .0 & 2.0, SETUP was called STATUS. 
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5.3 VMC Command Format 



VMC Command 

RESET 



Code 

08H 



VMC Data 



No data bytes 



This command is the vehicle that the VMC should use to tell the changer that it 
should return to its default operating mode. With the exception of the ACK 
response, it should abort all communication and disable all acceptance until 
otherwise instructed by the VMC. 



The following initialization sequence is recommended for all new VMCs designed after July, 2000. It should be used after "power up", 
after issuing the RESET command, or after issuing the Bus Reset (pulling the transmit line "active" for a minimum of 100 mS). 



POLL-0Bh 

To obtain "JUST RESET" response 

SETUP -09h 

To obtain changer level and configuration information 

EXPANSION IDENTIFICATION - OF OOh (Level 03+ only) 

To obtain additional changer information and options 

EXPANSION FEATURE ENABLE - OF 01 h (Level 03+ only) 

To enable desired options 

EXPANSION SEND DIAG STATUS -OF 05h (Level 03+ & option b1 only) 

To request the changer to report its current state of operation 

TUBE STATUS - OAh (Note 1 ) 

To obtain tube status / change information 

COIN TYPE-OCh 

To enable desired coin acceptance and disable manual coin payout if 
desired 

Note 1 - A minimum 500 msec delay is required between a reset (regardless of 
type) and the first TUBE STATUS command for certain models of the existing 
MDB coin changer field base. 
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VMC Command Code Changer Response Data 

SETUP 09H 23 bytes: Z1 - Z23 

Z1 = Changer Feature Level - 1 byte 



Indicates the feature level of the changer. This will distinguish the 
changers feature level to the VMC. Current defined levels: 

Level 2: Supports "core" command set. These are: RESET, 
STATUS, TUBE STATUS, POLL, COIN TYPE, and 
DISPENSE. (Z1 = 02h) 

Level 3: Supports level two and the EXPANSION command 
addition changer model number, manufacturer code, 
turning revision, etc. See the details of EXPANSION 
command later in this document. (Z1 =03h) 



Z2 - Z3 = Country / Currency Code - 2 bytes 

The packed BCD country / currency code of the changer can be 
sent in two different forms depending on the value of the left most 
BCD digit. 



If the left most digit is a 0, the International Telephone Code is used 
to indicate the country that the changer is set-up for. For example, 
the USA code is 00 01 H (Z2 = 00 and Z3 = 01 ). 

If the left most digit is a 1, the latest version of the ISO 4217 numeric 



currency code is used (see Appendix Al). For example, the code for the 



US dollar is 18 40H (Z2 = 18 and Z3 = 40) and for the Euro is 1978 (Z2 = 



19 and Z3 = 78). 



All new designs after July, 2000 must use the ISO 4217 numeric 
currency codes as listed in Appendix Al. 

Z4 = Coin Scaling Factor - 1 byte 
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All accepted coin values must be evenly divisible by this number. 
For example, this could be set to 05H for the USA nickel. 

Z5 = Decimal Places - 1 byte 

Indicates the number of decimal places on a credit display. For 
example, this could be set to 02H in the USA. 
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Z6 - Z7 = Coin Type Routing - 2 bytes 

Indicates what coin types can be routed to the Changer's tubes. 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Z6 Z7 

Bit is set to indicate a coin type can be routed to the tube. Valid 
coin types are to 1 5. 

Z8 - Z23 = Coin Type Credit - 1 6 bytes 

Indicates the value of coin types to 1 5. Values must be sent in 
ascending order. This number is the coin's monetary value divided 
by the coin scaling factor. Unused coin types are sent as 00H. 
Unsent coin types are assumed to be zero. It is not necessary to 
send all coin types. Coin type credits sent as FFH are assumed to 
be vend tokens. That is, their value is assumed to worth one vend. 

The bytes position in the 16 byte string indicates the coin type(s). 
For example, the first byte sent would indicate the value of coin 
type 0, the second byte sent would indicate the value of coin type 1 , 
and so on. For example, the USA coin types may be; Coin type = 
nickel, Coin type 1 = dime, Coin type 2 = quarter, Coin type 3 = 
dollar. 

VMC Command Code Changer Response Data 

TUBE STATUS OAH 1 8 bytes: Z1 - Z1 8 

Z1 - Z2 = Tube Full Status - 2 bytes 

Indicates status of coin tube for coin types to 15. 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Z1 Z2 

A bit is set to indicate a full tube. For example, bit 7 = set would 
indicate the tube for coin type 7 is full. 

Z3 - Z1 8 = Tube Status - 1 6 bytes 

Indicates the greatest number of coins that the changer "knows" 
definitely are present in the coin tubes. A bytes position in the 16 
byte string indicates the number of coins in a tube for a 
particular coin type. For example, the first byte sent indicates the 
number of coins in a tube for coin type 0. Unsent bytes are 
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assumed to be zero. For tube counts greater than 255, counts 
should remain at 255. 

NOTE: If a changer can detect a tube jam, defective tube sensor, or other 
malfunction, it will indicate the tube is "bad" by sending a tube full status and a 
count of zero for the malfunctioning coin type. 



VMC Command Code 



POLL 
Z1 - Z16 = 



OBH 

Changer Activity - 1 6 bytes 



Changer Response Data 

16 bytes: Z1 -Z16 



Indicates the changer activity. If there is nothing to report, the 
changer should send only an ACK. Otherwise, the only valid 
responses are: 



Coins Dispensed Manually: 



Z1 



Z2 



(lyyyxxxx) (zzzzzzzz) 



yyy 

xxxx 

zzzzzzzz 



The number of coins dispensed. 
The coin type dispensed (0 to 15) 
The number of coins in the tube. 



Coins Deposited: 

Z1 



Z2 



(Olyyxxxx) (zzzzzzzz) 

yy 



Status: 



xxxx 

zzzzzzzz 

(00000001) = 

(00000010) = 

(00000011) = 



Coin routing. 00: CASH BOX 
01: TUBES 
10: NOT USED 
11: REJECT 

Coin type deposited (0 to 1 5). 

The number of coins in the tube 
for the coin type accepted. 



Escrow request 1 - An escrow lever activation has 
been detected. 

Changer Payout Busy 2 - The changer is busy 
activating payout devices. 
No Credit 1 - A coin was validated but did not get 
to the place in the system when credit is given. 
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Slug: 



(00000100) 
(00000101) 
(00000110) 
(00000111) 
(00001000) 
(00001001) 
(00001010) 
(00001011) 

(00001100) 
(00001101) 



(001xxxxx) = 



Defective Tube Sensor 1 - The changer has detected 
one of the tube sensors behaving abnormally. 

Double Arrival 1 - Two coins were detected too 
close together to validate either one. 

Acceptor Unplugged 2 - The changer has detected 
that the acceptor has been removed. 

Tube Jam 1 - A tube payout attempt has resulted 
in jammed condition. 

ROM checksum error 1 - The changers internal 
checksum does not match the calculated checksum. 
Coin Routing Error 1 - A coin has been validated, 
but did not follow the intended routing. 

Changer Busy 2 - The changer is busy and can 
not answer a detailed command right now. 

Changer was Reset 1 - The changer has detected 
an Reset condition and has returned to its power- 
on idle condition. 

Coin Jam 1 - A coin(s) has jammed in the 
acceptance path. 

Possible Credited Coin Removal 1 - There has 
been an attempt to remove a credited coin. 

Note: 

changers must have a means to disable this code 

due to potential older VMC issues. 

virtually all VMCs designed prior to this code's 

introduction (10/16/02) will not support it. 

It is a vending machine system issue as to what is 

done when this code is received. 

xxxxx is the number of slugs since the last 
activity. 



NOTES: 



The Changer may send several of one type activity, up to 1 6 bytes total. 
This will permit zeroing counters such as slug, inventory, and status. 

1 Sent once each occurrence. 

2 Sent once each POLL 
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File Transport Layer POLLed responses: 



Note that all FTL responses are defined in Section 2.6. For the coin changer, the source address will always be the changer (08H) as 
defined in Section 2.3. 



Z1 



1 B REQ TO RCV 



The coin changer is requesting to 
receive data from a device or VMC. 



Z2 = Destination address of response 

Z3 = Source address of response (08H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



1C RETRY/DENY 



1D SEND BLOCK 



1E OK TO SEND 



The coin changer is requesting a device or 
VMC to retry or deny the last FTL command. 

Z2 = Destination address of response 
Z3 = Source address of response (08H) 
Z4 = Retry delay 

The coin changer is sending a block of data 
(maximum of 31 bytes) to a device or VMC. 

Z2 = Destination address of data 
Z3 = Block # 

Z4-Z34 = Data (maximum of 31 bytes) 

The coin changer is indicating that it 

is OK for a device or VMC to send it data. 



1F REQ TO SEND 



Z2 = Destination address of response 
Z3 = Source address of response (08H) 

The coin changer is requesting to 
send data to a device or VMC. 



Z2 = Destination address of response 

Z3 = Source address of response (08H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



VMC Command Code 



VMC Data 
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COIN TYPE 



OCH 



4 bytes: Y1 - Y4 



Y1 - Y2 = 



Coin Enable - 2 bytes 



b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y1 Y2 



A bit is set to indicate a coin type is accepted. For example, bit 6 is set to 
indicate coin type 6, bit 1 5 is set to indicate coin type 1 5, and so on. To disable 
the changer, disable all coin types by sending a data block containing 0000H. All 
coins are automatically disabled upon reset. 

Y3 - Y4 = Manual Dispense Enable - 2 bytes 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y3 Y4 

A bit is set to indicate dispense enable. For example, bit 2 is set to enable 
dispensing of coin type 2. This command enables/disables manual dispensing 
using optional inventory switches. All manual dispensing switches are 
automatically enabled upon reset. 
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VMC Command 

DISPENSE 



Code 

ODH 



VMC Data 

1 byte: Y1 



b7 b6 b5 b4 b3 b2 b1 bO 

Y1 

Bits b3, b2, b1 , bO indicate coin type to be dispensed. Valid codes are OH to FH 
to indicate coin types to 1 5. 



NOTE 1 : If two coin types have the same value, the highest coin type should 
be paid out first. 

NOTE 2: There is no defined limit on how long the actual dispense takes 



since the command allows for up to 1 5 coins to be paid out. The 
payout cycle begins when the changer ACKs the VMC's 
DISPENSE (ODH) command. This cycle typically lasts a minimum 
of 100 mS and ends when the changer stops dispensing the 
desired number of coins. VMCs should monitor the Changer 
Payout Busy response to the POLL command to 
determine when the entire payout cycle is completed. 

However, it must be noted that other than ACKing the DISPENSE 
(ODH) command, the changer does not have to respond during the 
payout cycle provided the payout cycle is less than the changer's 
non-response time and the changer starts responding again prior to 
the end of the non-response time. Thus, it is acceptable for the 
changer to never report Changer Payout Busy, but simply start 
ACKing the POLL commands upon completion of a payout cycle 
provided the non-response time has not been exceeded . 



Bits b7, b6, b5, b4 indicate the number of coins to be dispensed. 
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LEVEL THREE CAPABILITIES - EXPANSION COMMAND 

The following describes the currently defined expansion commands. 

Sub-command 00H is used for a changer that has the capability of reporting 
model number, serial number, and so on. 

VMC Command Code Sub-Command Changer Response Data 

EXPANSION OFH 00H 33 bytes: Z1 - Z33 

COMMAND IDENTIFICATION 



Z1 - Z3 = Manufacturer Code - 3 bytes 

Identification code for the equipment supplier. Sent as ASCII 
characters. Currently defined codes are listed in the EVA 
document entitled "European Vending Association Data 
Transfer Standard' (EVA-DTS), the Audit Data Lists section, sub- 
section 2, "Manufacturer Codes". 

Z4-Z15= Serial Number- 12 bytes 

Factory assigned serial number. All bytes must be sent as ASCII 
characters, zeros (30H) and blanks (20H) are acceptable. 

Z1 6 - Z27 = Model #/Tuning Revision - 1 2 bytes 

Manufacturer assigned model number and tuning number. All 
bytes must be sent as ASCII characters, zeros (30H) and blanks 
(20H) are acceptable. Each manufacturer should include 
information concerning the changer tuning revision. 

Z28 - Z29 = Software Version - 2 bytes 

Current software version. Must be sent in packed BCD. 

Z30 - Z33 = Optional Features - 4 bytes 

Each of the 32 bits indicate an optional features availability. If the 
bit is set the feature is available. Bits should be sent in descending 
order, i.e. bit 31 is sent first and bit is sent last. Currently defined 
options are: 

bO - Alternative Payout method. This method allows 

changer designs that determine change payout. That 
is, the payout algorithm may reside in the changer 
instead of the VMC. 



MDB/ICP Version 3.0 



March 26, 2003 



20 



Multi-Drop Bus / Internal Communication Protocol 



b1 - 



b2- 



b3 



Extended Diagnostic command supported. This 
command allows the VMC to request diagnostic 
status of the coin changer. 

Controlled Manual Fill and Payout commands 
supported. These commands allows the VMC to 
request the number of coin inserted or dispensed 
while the changer was in a controlled manual fill or 
payback mode. 

File Transport Layer (FTL) supported as defined in 
Section 2.6. 



b4- b31 



Available for future use 



VMC Command Code Sub-Command VMC Data 



EXPANSION 
COMMAND 



OFH 01 H 
FEATURE ENABLE 



4 bytes: Y1 - Y4 



This command is used to enable each of the optional features defined in Z30-Z33 
above. To enable a feature a bit is set to one. All optional features are 
disabled after reset. 



VMC Command Code Sub-command VMC Data Changer Response 



EXPANSION 
COMMAND 
(Alternative 
Payout) 

Y1 = 



OFH 02H 
PAYOUT 



Y1 



None 



Value of coins to be paid out - 1 byte 

This value is expressed as the number of coin scaling factors that 
would sum to the value. For example, in a USA system using a 
scaling factor of 05, if the change to be paid out is 75 cents, then 
Y1 will equal fifteen. That is, the sum of fifteen nickels equal 75 
cents. The coin changer will determine which actual denominations 
of coins will be paid out. In the 75 cent example, the coins may be 
3 quarters; or, 7 dimes & 1 nickel; or, 2 quarters & 2 dimes & 1 
nickel, etc. 
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VMC Command Code Sub-command 



EXPANSION 
COMMAND 
(Alternative 
Payout) 



OFH 03H 
PAYOUT STATUS 



VMC Data Changer Response 

None 16 bytes: Z1-Z16 



Z1 - Z1 6 = Number of each coin type paid out - 1 6 bytes 

This is the changer's response to the last VMC Alternative 
PAYOUT command (0FH-02H). Bytes are sent in ascending order 
of coin types. A bytes position in the string indicates the coin type. 
That is, byte one is the number of coins for coin type 1 , byte two is 
the number of coins for coin type two, and so on. Unsent bytes are 
assumed to be zero. 

The changer clears payout data after an ACK response from the 
VMC. 

The VMC should compare the value of the coins paid out to the 
(0FH-02H) Alternative PAYOUT command's Y1 . 

NOTES: 1 ) If the changer's payout is busy it will respond to the 

Alternative PAYOUT STATUS command with an ACK only. 

2) If no coins have been paid out, at least one zero valued data byte 
must be sent. 



3) There is no defined limit on how long the actual payout 
takes. See Note 2 under the DISPENSE (ODH) command. 



VMC Command Code Sub-command 



EXPANSION 
COMMAND 
(Alternative 
Payout) 

Z1 



OFH 04H 

PAYOUT VALUE POLL 



Changer Response Data 

1 byte: Z1 



Changer Payout Activity - 1 byte 

An interval value (scaled) which indicates the amount of paid 
out change since the previous PAYOUT VALUE POLL (or 
between the initial Alternative PAYOUT command (OFH- 
02H) and the first PAYOUT VALUE POLL). 
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An 00H response indicates no coins were paid out since the 
previous PAYOUT VALUE POLL (or the initial Alternative 
PAYOUT command (0FH-02H)). 



An ACK only indicates that the change payout is finished. This should be 
followed by the PAYOUT STATUS command (0FH-03H) to obtain the 
complete payout data. 

NOTE: The initial intent of this command is to determine the amount of change 
paid out so that the credit display can be decremented as coins are dispensed. 



VMC Command Code Sub-Command Changer Response Data 
EXPANSION OFH 05H 16 bytes: Z1 -Z16 

COMMAND SEND DIAGNOSTIC STATUS 

Send Current Diagnostic Status - This command requests the changer to report its 
current state of operation. The VMC should periodically transmit the command 
approximately every 1 to 1 seconds. 



Z1 -72. - Current changer diagnostic information 

The changer reports its current state of operation in a 2 byte code. Z1 is 
the main code and Z2 is the sub-code. The code is reported as long as the 
condition exists and stops being reported as soon as the condition does 
not exist. Multiple 2 byte codes may be sent in response to a single 
command which could result in a maximum of eight 2 byte codes (16 bytes 
total). 

The following tables identify the currently defined extended diagnostic 
codes: 
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Z1 / Z2 


Status 

V./ IU III W 


Causers) of Status / Error 


01 /oo 


Powering up 


Changer powering up / initialization 


02/00 


Powering down 


Changer powering down 


no / nn 
(Jo / UU 


UK 


Changer fully operational and ready to 
accept coins 


04/00 


Keypad shifted 


MODE key pressed and held so that 
LED flashes indicating keypad in shifted 
state. Reverts to normal mode if no key 
pressed for 1 5 seconds 


05/10 


Manual Fill / Payout active 


Manual Fill or Manual Payout mode of 
operation in progress (under control of 
the changer). This response must be 
reported at least once to allow the VMC 
to request a manual fill or manual 
payout report. 


r\ /- / on 

05 / 20 


New Inventory Information 
Available 


/"""\ ■ ■ ■ IV /I 1 • ■ 1 

Changer not in Manual inventory mode, 
but new inventory information available. 


06/00 


Inhibited by VMC 


All coin acceptance inhibited at request 
of VMC, possibly due to product 
dispenser jams, completely sold out, 
etc. 


10/Z2 


General changer error 


Z2 defined as: 

00 Non specific error. 

01 Check sum error #1 . A check sum error 
over a particular data range of configuration 
field detected. 

02 Check sum error #2. A check sum error 
over a secondary data range or 
configuration field detected. 

03 Low line voltage detected. The changer 
has disabled acceptance or payout due to a 
low voltage condition. 
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Z1 /Z2 


Status 


Cause(s) of Status / Error 


11 172 


Discriminator module error 


Z2 defined as: 

00 Non specific discriminator error. 

10 Flight deck open. 

11 Escrow Return stuck open. 
30 Coin jam in sensor. 

41 Discrimination below specified standard. 

50 Validation sensor A out of range. The 
acceptor detects a problem with sensor A. 

51 Validation sensor B out of range. The 
acceptor detects a problem with sensor B. 

52 Validation sensor C out of range. The 
apppntor Hptppt^ a nrohlpm with ^pn^or O 

Q^OC LUI UCICO lO CI Ul UUICI 1 1 Willi OCI IOUI W . 

53 Operating temperature exceeded. The 
acceptor detects the ambient temperature 
has exceeded the changer's operating 
range, thus possibly affecting the 
acceptance rate. 

54 Sizing optics failure. The acceptor 
detects an error in the sizing optics. 


12/Z2 


Accept gate module error 


Z2 defined as: 

00 Non specific accept gate error. 

30 Coins entered gate, but did not exit. 

31 Accept gate alarm active. 

40 Accept gate open, but no coin detected. 
50 Post gate sensor covered before gate 
opened. 


13 /Z2 


Separator module error 


Z2 defined as: 

00 Non specific separator error 

10 Sort sensor error. The acceptor detects 

an error in the sorting sensor. 


14 /Z2 


Dispenser module error 


Z2 defined as: 

00 Non specific dispenser error. 


15/Z2 


Coin Cassette / tube 


Z2 defined as: 




module error 


00 Non specific cassette error. 

02 Cassette removed . 

03 Cash box sensor error. The changer 
detects an error in a cash box sensor. 

04 Sunlight on tube sensors. The changer 
detects too much ambient light on one or 
more of the tube sensors. 
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Diagnostic Status EVA-DTS Correlation 

The Extended Diagnostic information reported may be used by the vending 
machine controller as desired (i.e., service mode displays); however, EVA-DTS 
data elements could also be used for reporting to a host system. Examples are: 

o Via a translation of the Z1/Z2 code to one of the Fault Lists as described 
in Section 10 of the EVA-DTS. 

o Via the EA201 Event Identification element with the format EAxxyy where 
xx = Z1 and yy = Z2. 

o Via a customer / manufacture specific coding scheme using the MA5xx 
fields. 



VMC Command Code Sub-Command Changer Response Data 
EXPANSION OFH 06H 1 6 bytes Z1 -Z1 6 

COMMAND SEND CONTROLLED MANUAL FILL REPORT 

Send Controlled Manual Fill Report -This command requests the changer to 
report the number of coins inserted during a changer controlled manual fill 
(controlled bulk fill) mode. While in this mode, the changer must not report coins 
inserted in response to the POLL command. 

Z1 -Z1 6 = number of controlled manual mode filled coins (by coin type) 

A single byte is reported for each coin type, to 15. For example, Z1 = 
number of coins of coin type added in a controlled manual fill mode. Any 
amount above 255 will be reported as 255, i.e. it will reach a maximum limit. 

Only coin types supportedare required to be reported. Counts for unsent 
coins types will be assumed to be unchanged. 

Notes: After power on, changer reset, closing of the machine door, or a change in 
controlled manual fill status in the changer (changer indicated it was in controlled 
manual fill mode via CM0510 then changed to any other state) the machine 
should request the controlled manual coin fill data from the changer using the 
above command. 

See EVA-DTS correlation at end of SEND CONTROLLED MANUAL PAYOUT 
REPORT (0F-07H) command. 
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VMC Command Code Sub-Command Changer Response Data 
EXPANSION OFH 07H 16 bytesZ1-Z16 

COMMAND SEND CONTROLLED MANUAL PAYOUT REPORT 

Send Controlled Manual Payout Report- This command requests the changer to 
report the number of coins dispensed during a changer controlled manual payout 
(controlled bulk dispense) mode. Note that this does not include the coins 
dispensed via the individual dispense switches. 

If the new Controlled Manual Fill / Payout command is implemented in the coin 
mech and enabled by the VMC (OFh, 01 h, bit 2 of Y1 to Y4), while in a controlled 
manual payout (dispense) mode, the changer must not report the coins paid out in 
response to the POLL command. Conversely, if the changer does not support the 
new command or the VMC does not enable it, the changer should report the coins 
paid out in response to the POLL command. 



Z1 -Z1 6 = number of controlled manual mode dispensed coins (by coin type) 

A single byte is reported for each coin type to 15. For example, Z1 = 
number of coins of coin type dispensed in a controlled manual payout 
mode. Any amount above 255 will be reported as 255, i.e. it will reach a 
maximum limit. 

Only coin types supported are required to be reported. Counts for unsent 
coin types will be assumed to be unchanged. 

Note: After power on, changer reset, closing of the machine door, or a change in 
controlled manual payout status in the changer (changer indicated it was in 
controlled manual payout mode via CM0510 then changed to any other state) the 
machine should request the controlled manual coin payout data from the changer 
using the above command. 



Controlled Manual Fill / Payout EVA-DTS Correlation 

The controlled manual fill and payout coin information may be used by the 
vending machine controller as desired (i.e., service mode displays); however, 
EVA-DTS data elements could be used for reporting to a host system. Examples 
are: 
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CA3XX 


CA4XX 


CA1 704 


CA1705 


Controlled Manual Fill 


0F06 


n/a 


0F06 


n/a 


VMC Tube Fill 


VMC 


n/a 


VMC 


n/a 


Controlled Manual Payout 


n/a 


0F07* 


n/a 


0F07* 


VMC Coin Payout 


n/a 


VMC 


n/a 


VMC 


Manual Dispense Switches 


n/a 


OB 


n/a 


OB 



*lf extended 0F06 & 0F07 commands are implemented. 
If extended 0F06 & 0F07 commands are not implemented in the coin mech 
or not enabled by the VMC, the coin mech will respond to the POLL 
command with the controlled manual payout coins. 

With the above, the CA3XX & CA4XX fields can continue to be the primary fields 
for cash audit and the CA1 704 & CA1 705 fields can be used for indicating 
controlled manually filled / dispensed coins. 

Coin Tube Audit Fields 

As a reference, below are the agreed CA1 7XX data elements that provide detailed 
coin tube count information and controlled-manual coin tube insertion / dispense 
information. These were approved by the EVA - DTS Technical Sub Committee on 
January 27, 1997. 



Block Data 
Identifier Contents 
Reference 



Charac- 
teristic 



Length 
Min Max 



Element 



CA1 7 Coin Type Number 

(per MDB coin type) 



N 



01 03 



CA1701 



Value of Coin 



N 



01 



08 



CA1702 



Number of Coins 
in Tube 



N 



01 08 



CA1703 



Number of Coins 
Inserted during 
Controlled-Manual Fill 



N 



01 08 



CA1 704 



Number of Coins 
Dispensed during 
Controlled-Manual Payout 



N 



01 08 



CA1705 
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Definitions: 

CM 701 The coin type number as referred to in the MDB Interface 
Specification. If not an MDB system, the number represents the coin's 
position in the coin set starting with the lowest value coin accepted. Note 
if two or more vintage of the same coin is accepted, the oldest one is first. 

For example, the Canadian coin types may be: 

Old Nickel 3 Quarter 

1 New Nickel 4 $1 Dollar 

2 Dime 5 $2 Dollar 



CM 702 The cash value of the coin (units base). 

For example, the Canadian coin types would be: 

Nickel 5 $1 Dollar 100 

Dime 10 $2 Dollar 200 

Quarter 25 



CM 703 The number of coins in the coin tube (or tubes if multiple 
tubes per coin) that are reported by the coin mech during normal vending 
operations. Note that this is the "best known tube count" and may be 
inaccurate if coins were manually added or removed by hand. 



CM 704 The number of coins inserted while the changer was in a 
Controlled manual fill mode. Controlled manual fill indicates that the coins 
are being inserted under the control of the coin mech or VMC. Coins are 
not being loaded by hand through the tops of the tubes. 



CM 705 The number of coins dispensed while the changer was in a 
controlled manual payout mode. Controlled manual payout indicates that 
the coins are being dispensed under the control of the coin mech or VMC. 
Coins are not being removed by hand by "dumping" the tubes. 
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VMC Command Code Sub-command VMC Data Changer Response 

EXPANSION * OFH FAH " Y1-Y5 ' Z1 - Zn (immediate or 

COMMAND FTL REQ TO RCV POLLed) 

The VMC is requesting to receiv e data from the changer whose destination address will always be (08H). Note that all FTL Commands / 
Responses are defined in Section 2.6. 

Y1 = Destination address of command (08H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1 DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 

or 

Z1 = 1 CH which indicates RETRY / DENY 

Z2 = Destination address of response 

Z3 = Source address of response (08H) 

Z4 = Retry delay 



VMC Command Code Sub-command VMC Data Changer Response 

EXPANSION OFH FBH Y1-Y3 None 

COMMAND FTL RETRY /DENY 

The VMC is retrying, denying, or aborting a data transfer to/from the changer whose destinat ion address will always be (08H). Note that all 
FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (08H) 

Y2 = Source address of command 

Y3 = Retry delay 
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VMC Command Code Sub-command VMC Data Changer Response 



EXPANSION OFH FCH Y1-Y33 None 

COMMAND FTL SEND BLOCK 



The VMC is sending data to the changer whose destination address will always be (08H). Note that all FTL Commands / Responses are 
defined in Section 2.6. 



Y1 = Destination address of command & data (08H) 

Y2 = Block # 

Y3 - Y33 = Data (maximum of 31 bytes) 



VMC Command Code Sub-command VMC Data Changer Response 

EXPANSION ^ OFH FDH ~ Y1-Y2 Z1 -Z34 (immediate or 

COMMAND FTL OK TO SEND POLLed) 

The VMC is indicating that it is OK for the changer to transfer data. The destination address will always be the changer (08H). Note that 
all FTL Commands / Responses are defined in Section 2.6. 



Y1 = Destination address of command (08H) 

Y2 = Source address of command 



Z1 = 1 DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Source address of data 

Z4 - Z34 = Data (maximum of 31 bytes) 
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VMC Command 

EXPANSION 
COMMAND 



Code Sub-command VMC Data Changer Response 

OFH FEH Y1-Y5 Z1 (immediate or 

FTL REQ TO SEND POLLed) 



The VMC is requesting to send data to the changer whose destination address will always be (08H). Note that all FTL Commands / 
Responses are defined in Section 2.6. 



Y1 = Destination address of command (08H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 



Z1 = 1EH which indicates OK TO SEND 

Z2 = Destination address of response 

Z3 = Source address of response (08H) 

or 

Z1 = 1 CH which indicates RETRY / DENY 

Z2 = Destination address of response 

Z3 = Source address of response (08H) 

Z4 = Retry delay 



VMC Command Code Sub-command VMC Data Changer Response 

EXPANSION OFH FFH " Y1-Yn " Z1-Zn 

COMMAND DIAGNOSTICS 



Y1 - Yn = Device manufacturer specific instruction for implementing various 
manufacturing or test modes. Y1 - Yn implies that any number of 
bytes can be used for the VMC data to the peripheral. 

Z1 - Zn = Device manufacturer specific responses after receiving 

manufacturing or test instructions. Z1 - Zn implies that any number 
of bytes can be used for the changer response data from the 
peripheral. 
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5.4 Changer Non-Response Time 



The maximum non-response time for the changer is two seconds. 
5.5 Changer Power Requirements 



The current draw for any changer must fall within the following limits. All 
measurements are at the minimum VMC Voltage Output. 

Idle mode = 200 mA. (max.) continuous 

Coin acceptance = 1 .8 A. (max.) for up to 2 seconds 

(For coin changers using solenoid based payout mechanisms - typical 
of 3 tube changers sold in the US market. Vending machines sold into 
the US market are required to supply this power.) 

1 .0 A. (max.) for up to 2 seconds 

(For coin changers using motorized payout 

mechanisms - typical of 4 tube changers.) 

Coin payout = 3.6 A. (max.) for 1 00 mS. with 400 mS. idle 

current between pulses during the coin payout 
cycle. 

(For coin changers using solenoid based payout mechanisms - typical 
of 3 tube changers sold in the US market. Vending machines sold into 
the US market are required to supply this power.) 

1 .8 A. (max.) during the coin payout cycle. 

(For coin changers using motorized payout mechanisms - typical of 4 
tube changers. 

See Note 2 under the DISPENSE (0DH) command for further information on the 
coin payout cycles.) 

Note: If both peripherals are supported, vending machines should be able to 
provide sufficient power to simultaneously supply the above power requirements 
for both the coin changer Coin Acceptance and bill validator Bill Transport as 
specified in Section 6.5. 
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Section 6 

Bill Validator 

VMC/Peripheral Communication Specifications 
6.1 Introduction 



This section defines the communication bytes sent and received between a Bill 
Validator and the VMC. As defined in Section 2.3, the bill validator's address is 
00110xxxB (30H). 

Unless stated otherwise, all information is assumed to be in a binary format. 

There are currently two levels of support defined for the bill validator interface, 
Level 1 and Level 2. The level of bill validator operation is sent to the VMC in the 
response to the STATUS command (defined later in this section). The following 
paragraphs will define how a VMC should differentiate between each level. 

Level 1 Bill Validators 

Level 1 bill validators support all standard functions, but do not support any 
optional features. 

Level 2 Bill Validators 

Level 2 bill validators support all standard functions plus various optional features 
as defined in Section 6.3 under the Expansion command 37-02H. Based on the 
optional feature information the VMC will determine the appropriate operating 
mode (in other words, modes that both the bill validator and the VMC can 
support), enable any appropriate features by sending an appropriate feature 
enable command back to the bill validator, and enter the proper operating mode. 
This technique allows all VMCs and peripherals to accommodate existing feature 
capabilities and provides a means for upgrading Level 2 equipment. 
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6.2 VMC Commands 



Command 

RESET 
SETUP* 
SECURITY 
POLL 
BILL TYPE 

ESCROW 
STACKER 



EXPANSION 
COMMAND 



Hex Code Description 

30H Command for bill validator to self-reset. 



31H 
32H 
33H 
34H 

35H 
36H 
37H 



Request for bill validator setup information. 

Sets Validator Security Mode 

Request for Bill Validator activity Status. 

Indicates Bill Type enable or disable. 
Command is followed by set-up data. 
See command format. 

Sent by VMC to indicate action for 
a bill in escrow. 

Indicates stacker full and the 
number of bills. 

Command to allow addition of features and 
future enhancements. Level 1 and above bill 
validators must support this command. 



NOTE: The expansion command is always followed by a sub-command. 



In Version 1 .0 & 2.0, SETUP was called STATUS. 
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6.3 VMC Command Format 



VMC Command 

RESET 



Code 

30H 



VMC Data 



No data bytes 



This command is the vehicle that the VMC should use to tell the validator that it 
should return to its default operating mode. It should reject any bills in the 
validation process, return any bills in the escrow position, and disable all other 
activity until otherwise instructed by the VMC. 



The following initialization sequence is recommended for all new VMCs designed after July, 2000. It should be used after "power up", 
after issuing the RESET command, or after issuing the Bus Reset (pulling the transmit line "active" for a minimum of 100 mS). 



POLL-33h 

To obtain "JUST RESET" response 

SETUP- 31 h 

To obtain bill validator level and configuration information 

EXPANSION IDENTIFICATION - 37 OOh (Level 01+) 

To obtain additional bill validator information 

EXPANSION IDENTIFICATION w/ OPTION BITS - 37 02h (Level 02+ only) 

To obtain additional bill validator information and options 

EXPANSION FEATURE ENABLE - 37 01 h (Level 02+ only) 

To enable desired options 

STACKER - 36h 

To obtain stacker status and number of bills 

BILL TYPE -34h 

To enable desired bill acceptance and desired bill escrow capability 
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VMC Command 

SETUP 



Code 

31H 



Validator Response Data 

27 bytes: Z1 - Z27 " 



Z2 - Z3 = 



Z4 - Z5 = 
Z6 

Z7 - Z8 = 



Bill Validator Feature Level - 1 byte 
tes current feature level of the bill validator. Currently defined 
are: 

Level 1 - does not support option bits (Z1=01h) 



Country / Currency Code - 2 bytes 

The packed BCD country / currency code of the bill validator can be 
sent in two different forms depending on the value of the left most 
BCD digit. 

If the left most digit is a 0, the International Telephone Code is used 
to indicate the country that the validator is set-up for. For example, 
the USA code is 00 01 H (Z2 = 00 and Z3 = 01 ). 

If the left most digit is a 1, the latest version of the ISO 4217 numeric 

currency code is used (see Appendix Al). For example, the code for the 

US dollar is 18 40H (Z2 = 18 and Z3 = 40) and for the Euro is 1978 (Z2 = 

19 and Z3 = 78). 



All new designs after July, 2000 must use the ISO 4217 numeric 
currency codes as listed in Appendix Al. 



Bill Scaling Factor - 2 bytes 

All accepted bill values must be evenly divisible by this number. 
For example, this could be set to 0064H for the USA. 

Decimal Places - 1 byte 

Indicates the number of decimal places on a credit display. For 
example, this could be set to 02H for the USA. 

Stacker Capacity - 2 bytes 

Indicates the number of bills that the stacker will hold. For 
example, 400 bill capacity = 01 90H. 



Level 2 - supports option bits 



(Z1 = 02h) 
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Z9 - Z1 = Bill Security Levels - 2 bytes 

Indicates the security level for bill types to 1 5. Since not all 
validators support multiple security levels, validators that do not 
have this feature must report a "high" security level. 



Z1 1 = Escrow/No Escrow - 1 byte 

Indicates the escrow capability of the bill validator. If Z1 1 = 00H, 
the bill validator does not have escrow capability. If Z1 1 = FFH, the 
bill 

validator has escrow capability. 

Z1 2 - Z27 = Bill Type Credit - 1 6 bytes 

Indicates the value of the bill types to 1 5. Values must be sent in 
ascending order. This number is the bill's monetary value divided 
by the bill scaling factor. Unused bill types are sent as 00H. 
Unsent bill types are assumed to be zero. FFH bills are assumed 
to be vend tokens. 

VMC Command Code VMC Data 

SECURITY 32H 2 Bytes: Y1 - Y2 

Y1 - Y2 = Bill Type(s) - 2 bytes 

b15 b>14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y1 Y2 

A bit is set to indicate the type of bill(s) which are set to a "high" 
security level. Note that validators that do not support dual security 
levels should report a "high" security level in the response bytes Z9- 
Z1 to the STATUS (31 H) command. 

VMC Command Code Validator Response Data 

POLL 33H 16 bytes: Z1 -Z16 

Z1 - Z1 6 = Bill Validator Activity - 1 6 bytes 

Indicates the validator activity, for example, the type and number of 
bills accepted, and stacker position. If there is nothing to report, the 
validator should send only an ACK. Otherwise, the only valid 
responses are: 

Bills Accepted: 

Indicates the type and number of bills accepted and stacker status. 

Z1 NOTE: These responses should be used to 

(1 yyyxxxx) add or subtract credit. 
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yyy = 

xxxx = 

Status: 

(00000001 
(00000010 

(00000011 
(00000100 

(00000101 
(00000110 
(00000111 

(00001000 
(00001001 
(00001010 
(00001011 
(00001100 



Bill Routing; 000: BILL STACKED 

001: ESCROW POSITION 
010: BILL RETURNED 
011: NOT USED 
100: DISABLED BILL 
REJECTED 

Bill Type (0 to 15) 



Defective Motor 3 - One of the motors has failed to 
perform its expected assignment. 

Sensor Problem 3 - One of the sensors has failed 
to provide its response. 

Validator Busy 2 - The validator is busy and can 
not answer a detailed command right now. 
ROM Checksum Error 3 - The validators internal 
checksum does not match the calculated 
checksum. 

Validator Jammed 3 - A bill(s) has jammed in the 
acceptance path. 

Validator was reset 1 - The validator has been 
reset since the last POLL. 

Bill Removed 1 - A bill in the escrow position has 
been removed by an unknown means. A BILL 
RETURNED message should also be sent. 
Cash Box out of position 3 - The validator has 
detected the cash box to be open or removed. 

Unit Disabled 2 - The validator has been disabled, 
by the VMC or because of internal conditions. 

Invalid Escrow request 1 - An ESCROW command 
was requested for a bill not in the escrow position. 

Bill Rejected 1 - A bill was detected, but rejected 
because it could not be identified. 

Possible Credited Bill Removal 1 - There has 
been an attempt to remove a credited (stacked) 
bill. 

Note: 

validators must have a means to disable this code 

due to potential older VMC issues. 

virtually all VMCs designed prior to this code's 

introduction (10/16/02) will not support it. 

It is a vending machine system issue as to what is 

done when this code is received. 
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(010xxxxx) = 



Number of attempts to input a bill while validator 
is disabled. 1 



NOTE: The validator may send several of one type activity up to 1 6 bytes total. 



1 Sent once each occurrence. 

2 Sent once each POLL 

3 Sent once each occurrence. The unit is then disabled until the 
condition is removed. Validator will respond with unit disabled 
until repaired or replaced. 
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File Transport Layer POLLed responses: 

Note that all FTL responses are defined in Section 2.6. For the bill validator, the source address will always be the validator (30H) as 
defined in Section 2.3. 



Z1 



1 B REQ TO RCV The bill validator is requesting to 

receive data from a device or VMC. 



Z2 = Destination address of response 

Z3 = Source address of response (30H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



1 C RETRY/DENY The bill validator is requesting a device or 

VMC to retry or deny the last FTL command. 

Z2 = Destination address of response 
Z3 = Source address of response (30H) 
Z4 = Retry delay 

1D SEND BLOCK The bill validator is sending a block of data 

(maximum of 31 bytes) to a device or VMC. 

Z2 = Destination address of data 
Z3 = Block # 

Z4-Z34 = Data (maximum of 31 bytes) 

1E OK TO SEND The bill validator is indicating that it is OK for 

the device or VMC to send it data. 



Z2 = Destination address of response 
Z3 = Source address of response (30H) 



1 F REQ TO SEND The bill validator is requesting to 

send data to a device or VMC. 



Z2 = Destination address of response 

Z3 = Source address of response (30H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 
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VMC Command Code VMC Data 



BILL TYPE 34H 4 bytes: Y1 - Y4 

Y1 - Y2 = Bill Enable - 2 bytes 

Indicates what type of bills are accepted. 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y1 Y2 

Bill types are to 1 5. A bit is set to indicate acceptance of bill type. 

NOTE: Sending 0000H disables the bill validator. 

Y3 - Y4 = Bill Escrow Enable: 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y3 Y4 

Bill types are to 1 5. A bit is set to indicate enable of escrow for a 
bill type. 

NOTE: On power-up or reset all bill acceptance and escrow are disabled. 

VMC Command Code VMC Data 

ESCROW 35H 1 byte: Y1 

Y1 = Escrow status - 1 byte 

If Y1 = 0; Return bill in the escrow position. 

If Y1 = xxxxxxxl ; Stack the bill ("x" indicates don't 

care) 

NOTE: After an ESCROW command the bill validator should respond to a POLL 
command with the BILL STACKED, BILL RETURNED, or INVALID ESCROW message 
within 30 seconds. If a bill becomes jammed in a position where the customer may be 
able to retrieve it, the bill validator should send a BILL RETURNED message. 
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VMC Command 

STACKER 



Code 

36H 



Validator Response Data 

2 bytes: Z1 - Z2 



Indicates stacker full condition and the number of bills in the stacker. 



Z1 



Z2 



(Fxxxxxxx) (xxxxxxxx) 

F = 1 if stacker is full, if not. 

xxxxxxxxxxxxxxx = The number of bills in the stacker. 



LEVEL ONE and TWO+ CAPABILITIES - EXPANSION COMMAND 

In order to allow existing VMCs to operate with original Level 1 or new Level 2 bill 
validators, a separate identification sub-command has been introduced to handle 
the additional 4 bytes of Option Bit information. 

The original sub-command 00H is used for obtaining Z1 to Z29 identification 
information from bill validators. This information includes the model number, 
serial number, software version, etc, but not the option bits . Note that if a 
Level 2+ bill validator is sent the 00H sub-command, it must not report the 
Z30 to Z33 option bytes. 

Sub-command 01 H is used for Level 2+ bill validators to enable option bits 
reported in the expansion command 02H sub-command below. 

The new sub-command 02H is used for obtaining Z1 to Z33 identification 
information from Level 2+ bill validators. This information includes the model 
number, serial number, software version, etc, and the option bits (Z30-Z33). 



VMC Command Code Sub-Command Validator Response Data 

EXPANSION " 37H 00H ' 29 bytes: Z1 - Z29 

COMMAND LEVEL 1 IDENTIFICATION WITHOUT OPTION BfTS 



Z1 - Z3 = Manufacturer Code - 3 bytes 



Identification code for the equipment supplier. Sent as ASCII 
characters. Currently defined codes are listed in the EVA 
document entitled " European Vending Association Data 
Transfer Standard' (EVA-DTS), the Audit Data Lists section, sub- 
section 2, "Manufacturer Codes". 
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Z4- Z15 = 




Serial Number - 12 bytes 

Factory assigned serial number. All bytes must be sent as ASCII 
characters, zeros (30H) and blanks (20H) are acceptable. 



Z1 6 - Z27 = Model #/Tuning Revision - 1 2 bytes 

Manufacturer assigned model number. All bytes must be sent as 
ASCII characters, zeros (30H) and blanks (20H) are acceptable. 



Z28 - Z29 = Software Version - 2 bytes 

Current software version. Must be sent in packed BCD. 



VMC Command Code Sub-Command VMC Data 

EXPANSION 37H 01 H 4 bytes: Y1 - Y4 

COMMAND LEVEL 2+ FEATURE ENABLE 

This command is used to enable each of the Level 2+ optional features defined in 
the Level 2+ Identification response bytes Z30-Z33 below. To enable a feature a 
bit is set to one. All optional features are disabled after reset. 



VMC Command Code Sub-Command Validator Response Data 

EXPANSION 37H 02H ' 33 bytes: Z1 - Z33 

COMMAND LEVEL 2+ IDENTIFICATION WITH OPTION BITS 

Z1 - Z3 = Manufacturer Code - 3 bytes 

Identification code for the equipment supplier. Sent as ASCII 
characters. Currently defined codes are listed in the EVA 
document entitled " European Vending Association Data 
Transfer Standard' (EVA-DTS), the Audit Data Lists section, sub- 
section 2, "Manufacturer Codes". 

Z4-Z15= Serial Number- 12 bytes 

Factory assigned serial number. All bytes must be sent as ASCII 
characters, zeros (30H) and blanks (20H) are acceptable. 

Z1 6 - Z27 = Model #/Tuning Revision - 1 2 bytes 

Manufacturer assigned model number. All bytes must be sent as 
ASCII characters, zeros (30H) and blanks (20H) are acceptable. 

Z28 - Z29 = Software Version - 2 bytes 

Current software version. Must be sent in packed BCD. 

Z30 - Z33 = Optional Features - 4 bytes 

Each of the 32 bits indicate an optional features availability. If the 
bit is set the feature is available. Bits should be sent in descending 
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order, i.e. bit 31 is sent first and bit is sent last. Currently defined 
options are: 

bO - File Transport Layer (FTL) supported as defined in 

Section 2.6. 
b1 - b31 Available for future use 

VMC Command Code Sub-command VMC Data Validator Response 

EXPANSION " 37H FAH Y1-Y5 " " Z1 (immediate or 

COMMAND FTL REQ TO RCV POLLed) 

The VMC is requesting to receive data from the bill validator whose destination address will always be (30H). Note that all FTL 
Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (30H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 

or 

Z1 = 1CH which indicates RETRY/ DENY 

Z2 = Destination address of response 

Z3 = Source address of response (30H) 

Z4 = Retry delay 



VMC Command Code Sub-command VMC Data Validator Response 

EXPANSION 37H FBH Y1-Y3 None 

COMMAND FTL RETRY /DENY 

The VMC is retrying, denying, or aborting a data transfer to/from the bill validator whose destination address will always be (30H). Note 
that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (30H) 

Y2 = Source address of command 

Y3 = Retry delay 



VMC Command Code Sub-command VMC Data Validator Response 

EXPANSION 37H FCH Y1-Y33 None 

COMMAND FTL SEND BLOCK 
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The VMC is sending data to the bill validator whose destination address will always be (30H). Note that all FTL Commands / Responses 
are defined in Section 2.6. 



Y1 = Destination address of command & data (30H) 

Y2 = Block # 

Y3 - Y33 = Data (maximum of 31 bytes) 



VMC Command Code Sub-command VMC Data Validator Response 

EXPANSION 37H FDH Y1-Y2 ~ Z1 -Z34 (immediate or 

COMMAND FTL OK TO SEND POLLed) 

The VMC is indicating that it is OK for the bill validator to transfer data. The destination address will always be the validator (30H). Note 
that all FTL Commands / Responses are defined in Section 2.6. 



Y1 = Destination address of command (30H) 

Y2 = Source address of command 

Z1 = 1DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Source address of data 

Z4 - Z34 = Data (maximum of 31 bytes) 



VMC Command Code Sub-command VMC Data Validator Response 

EXPANSION 37H FEH ~™ Y1-Y5 Z1 (immediate or 

COMMAND FTL REQ TO SEND POLLed) 

The VMC is requesting to send data to the bill validator whose destination address will always be (30H). Note that all FTL Commands / 
Responses are defined in Sect ion 2.6. 



Y1 = Destination address of command (30H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 
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Z1 = 1EH which indicates OK TO SEND 

Z2 = Destination address of response 

Z3 = Source address of response (30H) 

or 

Z1 = 1 CH which indicates RETRY / DENY 

Z2 = Destination address of response 

Z3 = Source address of response (30H) 

Z4 = Retry delay 



VMC Command Code Sub-Command VMC Data Val Response 

EXPANSION ~ 37H FFH Y1-Yn Z1 - Zn 

COMMAND DIAGNOSTICS 



Y1 - Yn = Device manufacturer specific instruction for implementing various 
manufacturing or test modes. Y1 - Yn implies that any number of 
bytes can be used for the VMC data to the peripheral. 

Z1 - Zn = Device manufacturer specific responses after receiving 

manufacturing or test instructions. Z1 - Zn implies that any number 
of bytes can be used for the bill validator response data from the 
peripheral. 

6.4 Bill Validator Non-Response Time 



The maximum non-response time for the bill validator is five seconds. 
6.5 Bill Validator Power Requirements 



The current draw for any bill validator must fall within the following limits. All 
measurements are at the minimum VMC Voltage Output. 

Idle mode = 200 mA. (avg.) continuous 

Bill transport = 2.5 A. (max.) up to 1 seconds 

Note: If both peripherals are supported, vending machines should be able to 
provide sufficient power to simultaneously supply the above power requirements 
for both the bill validator Bill Transport and coin mechanism Coin Acceptance 
as specified in Section 5.5. 
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Section 7 

Cashless Device(s) 

VMC/Peripheral Communication Specifications 

7.1 Introduction 

This section defines the communications bytes sent and received between the cashless device(s) 
and the Vending Machine Controller (VMC). As defined in Section 2.3, there are two cashless 
device addresses; Cashless #1, OOOlOxxxB (10H) and Cashless #2, llOOxxxB (60H). The 
second address has been assigned to allow for two unique forms of cashless devices to be 
resident in the vending machine simultaneously. An example would be a card based system as 
Cashless Device #1 (10H) and a mobile phone based system as Cashless Device #2 (60H). 
Everything defined in this section will be common to the two cashless devices - only the 
addresses will be different. 

Unless otherwise stated, all monetary values used by the cashless devices and the VMC will be 
sixteen bit (Level 01 & 02) or thirty-two bit (Level 03 if 32 bit option enabled), unsigned binary 
numbers. The numbers will be sent most significant byte first and scaled using the parameters 
provided by the cashless device's READER CONFIGURATION DATA response. 

7.2 State Definitions 

MDB cashless devices may be viewed as state machines. These states are as follows: 

1) Inactive 

2) Disabled 

3) Enabled 

4) Session Idle 

5) Vend 

6) Revalue (Level 02/03 cashless devices) 

7) Negative Vend (Level 03 cashless devices) 

7.2.1 Inactive 

This is the state of the cashless device at power up or after a reset. While in the Inactive state, 
cashless devices will NOT be accepted for vending purposes. The cashless device cannot leave 
this state until all Setup information is received from the VMC. 

7.2.2 Disabled 

The cashless device automatically enters this state from the Inactive state when it has received 
the Setup information specified in 7.4.1. It will also enter the Disabled state from the Enabled 
state when it receives the READER DISABLE command. While in the Disabled state, payment 
medias will NOT be accepted for vending purposes. The cashless device will remain in this state 
until either a READER ENABLE command is received (when it will enter the Enabled state) or 
a RESET is received (when it will enter the Inactive state). For power management purposes, 
current consumption will not exceed idle mode specification during disabled state. 

7.2.3 Enabled 

In this state, cashless devices may be used for MDB transactions. The cashless device will 
remain in this state until a valid payment media is read (when it will enter the Session Idle state), 
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a READER DISABLE command is received (when it will return to the Disabled state) or a 
RESET is received (when it will enter the Inactive state). 

7.2.4 Session Idle 

In the Enabled state, when a valid payment media is processed, the cashless device will issue a 
BEGIN SESSION response to a VMC POLL and enter the Session Idle state. This indicates that 
the cashless device is available for vending activities. The only structured exit from the Session 
Idle state is through the SESSION COMPLETE message from the VMC. The SESSION 
COMPLETE command will cause the cashless device to respond with an END SESSION 
message and enable/disable itself appropriately. Vend / Negative Vend / Revalue commands will 
cause the cashless device to leave the Session Idle state and enter the Vend / Negative Vend / 
Revalue state when products are selected and purchased. 

7.2.5 Vend 

This state is entered from the Session Idle state upon reception of a VEND REQUEST message 
from the VMC. The entire Vend state is an uninterruptable command/response sequence. The 
cashless device will return to the Session Idle state upon completion of this sequence. 

7.2.6 Revalue (Level 02 / 03 Cashless Devices) 

This state is entered from the Session Idle state upon reception of a REVALUE REQUEST 
message from the VMC. The entire Revalue state is an uninterruptable command/response 
sequence. The cashless device will return to the Session Idle state upon completion of this 
sequence. 

7.2.7 Negative Vend Request (Level 03 Cashless 
Devices) 

This state is entered from the Session Idle state upon reception of a NEGATIVE VEND 
REQUEST message from the VMC. The entire Negative Vend Request state is an 
uninterruptable command/response sequence. The cashless device will return to the Session Idle 
state upon completion of this sequence. 

7.3 Command Protocol 

After the VMC has issued a command, no new commands may be issued until all data generated 
in response to that command has been received from the cashless device. The complete response 
may be an ACK only (e.g. the READER ENABLE command). Alternatively, it may consist of 
an informational response (e.g. READER CONFIGURATION DATA). 
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The cashless device may provide an informational response in two ways. It may respond 
immediately with the requested data, or the cashless device may ACK the VMC command. If 
ACKed, the VMC must issue POLLs until the cashless device responds with the requested data, 
or until the Application Maximum Response Time (defined in READER CONFIGURATION 
response) has elapsed. 

The cashless device will define the currency type at the beginning of each session. The 
currency type will be used for all following transactions in that session If the VMC does 
not support this currency type, it will end the session. 



Below are the uninterruptable VMC commands which require an informational cashless device 
response and their associated result: 



VMC Command 


Cashless Device Response 


Result 


SETUP/CONFIGURATION DATA => 


READER CONFIGURATION 
DATA 




EXPANSION/REQUEST ID => 


PERIPHERAL ID 




READER CANCEL => 


CANCELLED 




VEND REQUEST... VEND CANCEL => 


VEND DENIED* 




VEND REQUEST => 


VEND DENIED* 




VEND REQUEST => 


VEND APPROVED => 


VEND SUCCESS* 


VEND REQUEST => 


VEND APPROVED => 


VEND FAILURE* 


NEGATIVE VEND REQUEST => 


NEGATIVE VEND DENIED* 




NEGATIVE VEND REQUEST => 


NEGATIVE VEND 


NEGATIVE VEND 




APPROVED => 


SUCCESS* 


NEGATIVE VEND REQUEST => 


NEGATIVE VEND 


NEGATIVE VEND 




APPROVED => 


FAILURE* 


REVALUE REQUEST=> 


REVALUE 

APPROVED/DENIED* 




SESSION COMPLETE => 


END SESSION 





*These VEND / NEGATIVE VEND / REVALUE REQUEST response sequences constitute the 
Vend / Negative Vend / Revalue Request states. 



Below are the uninterruptable POLLed cashless device which require an informational response 
from the VMC: 



VMC Command & Data 


Cashless Device Response 


Result 


POLL => 


DATA ENTRY REQUEST + 
DISPLAY REQUEST (optional) 




POLL => 


DATA ENTRY CANCEL 


Cancelled 


DATA ENTRY RESPONSE w/ FFs => 




Cancelled 



Any command may be issued by the VMC at anytime providing the above command protocol is 
observed. There are four exceptions to this rule: 



MDB/ICP Version 3.0 



March 26, 2003 



51 



Multi-Drop Bus / Internal Communication Protocol 



1) VEND REQUEST, REVALUE REQUEST, and NEGATIVE VEND 
REQUEST response sequences may only be initiated in the Session 
Idle state. 

2) The VMC may issue a VEND CANCEL command after issuing a VEND 
REQUEST, but before receiving a VEND APPROVED/DENIED response. In 
this case the cashless device will issue a VEND DENIED response to satisfy 
the original VEND REQUEST response requirement. 

3) The cashless device may issue DISPLAY REQUESTS in response to POLLs 
at any time, if the VMC's display is available for use. 

4) The RESET command is allowed at any time, it is not subject to any restrictions. 

If a VMC command is received by the cashless device while it is in one of the preceding 
uninterruptable states, the following will occur: 

The cashless device will ACK the offending command (no data response will 
be forthcoming). The cashless device will respond to the next poll with the 
"COMMAND OUT OF SEQUENCE" response (OBH). 

It should be pointed out to cashless device developers that a command out of 
sequence will always cause the VMC to issue a RESET command to the cashless 
device. 

7.3.1 Multi-Message Response Format 

The multi- message response format permits the cashless device to send multiple messages in 
response to a single command or POLL. Because all messages are of a fixed length, there is no 
confusion determining where one message ends and the next message begins. (The total 
message length is subject to the 36 byte limit imposed by Section 2 of this standard.) 

For example, if a cashless device fails to correctly write a payment media after a VEND 
REQUEST, it may need to report: 

1) VEND DENIED 

2) MALFUNCTION/ERROR subcode 07h 

3) SESSION CANCEL REQUEST 

The multi- message response (hex) would look like this: 



06 


OA 07 


04 


IB 










1 


2 


3 


4 



The first byte above (marked 1) is the VEND DENIED message. The next two bytes (marked 2) 
are the MALFUNCTION/ERROR message. The third and final message is the CANCEL 
SESSION REQUEST (marked 3). An eight bit checksum with the mode bit set (marked 4) 
finishes the message. 
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It is important to note that the controller must service the messages in the order in which they are 
received. This is necessary to ensure that command protocol is maintained. 
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7.3.2 Coin Mechanism Escrow Return Actions 

If present, the cashless device return button is controlled by the cashless device and it is the 
responsibility of the cashless device to terminate a vend sequence if the return button is pressed 
during a vend sequence. 



The reaction of the VMC to the coin mechanism escrow return will vary depending upon the 
state of the system at the time it is pressed. If escrow return is allowed then a coin mechanism 
escrow return should be interpreted as VEND CANCEL or END OF SESSION. 



1) In the Enabled state, the VMC should send a READER CANCEL command to 
the cashless device. This allows the user to abort a pre-approved on-line 
authorisation request. 

2) In the Session Idle state, the VMC should send a SESSION COMPLETE 
command to the cashless device. This will return the cashless device to the 
Enabled state. The escrow return may cause the system to enter the revalue 
state prior to the VMC sending the "SESSION COMPLETE" command. 

3) In the Vend state, before the cashless device has sent a VEND APPROVED 
or a VEND DENIED, the VMC should send a VEND CANCEL command to the 
cashless device. This will cancel the vend and cause the cashless device to 
refund the payment media if necessary. 

4) In all other cases, no message is sent from the VMC to the cashless device. 
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TABLE 1: COMMANDS & RESPONSES 



Command 



Code 



Sub-command / Data 



Response 



VMC / Cashless 
Level Support 



Reset 



10H 
60H 



(none) 



No Data * 



(Level 01+) 



Setup 



11H 
61H 



00H - Config Data 



01H- Reader Config 
Data 



(Level 01+) 



01 H - Max/Min Prices 



No Data * 



(Level 01+) 



Poll 



12H 
62H 



(none) 



00H - Just Reset 
01H - Reader Config Data 
02H - Display Request 
03H - Begin Session 
04H - Session Cancel 

Request 
05H - Vend Approved 
06H - Vend Denied 
07H - End Session 
08H - Cancelled 
09H - Peripheral ID 
OAH - Malfunction / Error 
OBH - Cmd Out Of 

Sequence 
ODH - Revalue 

Approved 
OEH - Revalue Denied 
OFH - Revalue Limit 

Amount 
10H - User File Data 
11H- Time/Date 

Request 
12H - Data Entry 

Request 

13H - Data Entry Cancel 
14H-1AH 

1BH - FTL REQ TO RCV 
1CH - FTL RETRY / 

DENY 
1DH - FTL SEND 

BLOCK 
1EH - FTL OK TO SEND 
1FH - FTL REQ TO 

SEND 



(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 

(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 
(Level 01+) 

(Level 02+) (option) 

(Level 02+) (option) 

(Level 02+) (option) 

(Level 02) ** 
(Level 02+) (option) 

(Level 03+) (option) 

(Level 03+) (option) 
(For Future Use) 
(Level 03+) (option) 
(Level 03+) (option) 

(Level 03+) (option) 

(Level 03+) (option) 
(Level 03+) (option) 

(For Future Use) 
(Level 01+) 
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20H - FEH 

FFH - Diagnostic Response 




Vend 


13H 
63H 


00H - Vend Request 


05H - Vend Approved 
06H - Vend Denied 


(Level 01+) 
(Level 01+) 


01H - Vend Cancel 


06H - Vend Denied 


(Level 01+) 


02H - Vend Success 


No Data * 


(Level 01+) 


03H - Vend Failure 


No Data * 


(Level 01+) 


04H - Session Complete 


07H - End Session 


(Level 01+) 


Af TT /~1 1 CI 1 

05H - Cash Sale 


No Data * 


(Level 01+) 


A/"TT XT a' "\ T J 

06H - Negative Vend 
Request 


05 H - Vend Approved 
Uorl - Vend Denied 


(Level 03+) option) 
(Level 03+) (option) 


Reader 


14H 
64H 


00H - Reader Disable 


No Data * 


(Level 01+) 


01 H - Reader Enable 


No Data * 


(Level 01+) 


02H - Reader Cancel 


08H - Cancelled 


(Level 01+) 


03H - Data Entry 
Response 


No Data * 


(Level 03+) (option) 


Revalue 

(option) 


15H 
65H 


00H - Revalue Request 


ODH - Revalue Approved 
OEH - Revalue Denied 


(Level 02+) (option) 
(Level 02+) (option) 


01H - Revalue Limit 
Request 


OFH - Revalue Limit 

Amount 
OEH - Revalue Denied 


(Level 02+) (option) 
(Level 02+) (option) 


Expansion 


17H 
67H 


00H - Request ID 


09H - Peripheral ID 


(Level 01+) 


01 H- Read User File 


10H - User File Data 


(Level 02) ** 


02H - Write User File 


No Data * 


(Level 02) ** 


03H - Write (option) 
Time/Date 


No Data * 


(Level 02+) (option) 


04H - Optional Feature 
Enabled 


No Data 


(Level 03+) 


FAH - FTL (option) 
REQTO RCV 


1DH - SEND BLOCK 
1CH - RETRY / DENY 


(Level 03+) (option) 
(Level 03+) (option) 


FBH - FTL (option) 
RETRY /DENY 


No Data 


(Level 03+) (option) 


FCH - FTL (option) 
SEND BLOCK 


No Data 


(Level 03+) (option) 


FDH - FTL (option) 
OK TO SEND 


1DH - SEND BLOCK 


(Level 03+) (option) 


FEH - FTL (option) 
REQTO SEND 


1EH - OK TO SEND 
1CH - RETRY/DENY 


(Level 03+) (option) 
(Level 03+) (option) 


FFH - Diagnostics 


FFH - Diagnostic Response 


(Level 01+) 



* No Data response = peripheral just responds with ACK or NAK 

** Obsolete Command - Do not use for new designs. Use EXPANSION - Diagnostics. 

The term (option) indicates that the command/response is a feature enabled by option bits. 
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NOTE: Cashless device responses which are part of request / response sequences are listed more 
than once in the above table since the cashless device may respond either immediately to the 
request (within 5 milliseconds) or to a later POLL. 

7.4 VMC/ Cashless Device Command/Response Formats 

In the following section, the term "Reader" will indicate either Cashless Device #1 or #2. 

7.4.1 Reset and Initialising 

RESET 
(10H/60H) 



Reader response: 

No Data response 

If this command is received by a cashless device it should terminate any ongoing transaction 
(with an appropriate credit adjustment, if appropriate), eject the payment media (if applicable), 
and go to the Inactive state. 

All Level 02 and above VMCs must follow the RESET command with the following cashless 
device initializing sequence: (Any new Level 01 VMCs are recommended to follow the 
sequence.) 

Note that the example shows commands for Cashless Device #1 (10H) only. They would be the 
same for Cashless Device #2 (address 60H). 

POLL - 12h 

To obtain "JUST RESET" response 

SETUP CONFIGURATION DATA - 11 OOh 

To send the VMCs configuration data and obtain the cashless device's data 

SETUP MAX/MIN PRICE - 11 Olh 

To send the maximum and minimum prices in the VMC. These prices must be 
sent as Level 01/02 16 bit credit. 
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EXPANSION REQUEST ID - 17 OOh 

To obtain additional cashless device information and options ( options in Level 03+ only) 

EXPANSION ENABLE OPTIONS - 17 04h (Level 03+ only) 

To enable desired options 

SETUP MAX/MIN PRICE - 11 Olh (Level 03+ and option bits 1 & 2 only) 

If 32 bit currency option and/or multi currency - multi lingual is enabled (i.e. bits 1 & 2 
of expansion enable options), perform SETUP MAX/MIN PRICE again to get 32 bit 
credit and/or user currency - user language (this conditions will be known as 
EXPANDED CURRENCY MODE in the rest of the document). 

READER ENABLE - 14 Olh 

To enable cashless device (if desired) 



7.4.2 SETUP - Config Data 





Config 


VMC 


Columns 


Rows 


Display 


SETUP 


Data 


Feature 


on 


On 


Info 


(11H/61H) 


(OOH) 


Level 


Display 


Display 






Yl 


Y2 


Y3 


Y4 


Y5 



Yl : Configuration data. 

VMC is sending its configuration data to reader. 

Y2 : VMC Feature Level. 

Indicates the feature level of the VMC. The available feature levels are: 



01 - The VMC is not capable or will not perform the advanced features as 

specified in Table 1: COMMANDS & RESPONSES following Section 
7.3.2. The reader will not provide advanced information to the VMC, but 
can do the advanced features internally (transparently to the VMC). The 
reader has no revaluation capability. 

02 - The VMC is capable and willing to perform the advanced features as 

specified in Table 1: COMMANDS & RESPONSES following Section 
7.3.2. The reader will provide advanced information to the VMC (if 
possible) and will not do the advanced features internally. 

03 - The VMC is able to support level 02, but also supports some or all of the 

optional features listed in the EXPANSION ID command (i.e., file transfer, 
32 bit credit, multi- currency / language features, negative vend, and / or 
data entry). 

Y3 : Columns on Display. The number of columns on the display. Set to OOH if the 
display is not available to the reader. 
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Y4 : Rows on Display. 

The number of rows on the display 

Y5 : Display Information - xxxxxyyy 
xxxxx = Unused 
yyy = Display type 

000 : Numbers, upper case letters, blank and decimal point. 

001 : Full ASCII 
010-111: Unassigned 



Reader Response: 



Reader 


Reader 


Country 


Country 


Scale 


Decimal 


Application 


Miscellaneous 


Config 


Feature 


Code 


Code 


Factor 


Places 


Maximum 


Options 


Data 


Level 


High 


Low 






Response 




(01H) 












Time 




Zl 


Z2 


Z3 


Z4 


Z5 


Z6 


Z7 


Z8 



READER - Configuration data. 

Indicates the payment media reader is responding to a SETUP - Configuration 
data request from the VMC. 

Reader Feature Level. 

Indicates the feature level of the reader. Currently feature levels are: 

01 - The reader is not capable or will not perform the advanced features as 
specified in Table 1: COMMANDS & RESPONSES following Section 
7.3.2. The reader will not provide advanced information to the VMC, but 
can do the advanced features internally (transparently to the VMC). The 
reader has no revaluation capability. 

02 - The reader is capable and willing to perform the advanced features as 
specified in Table 1: COMMANDS & RESPONSES following Section 
7.3.2. The reader will provide advanced information to the VMC (if 
possible) and will not do the advanced features internally. 

03 - The reader is able to support level 02, but also supports some or all of the 
optional features listed in the EXPANSION ID command (i.e., file 
transfer, 32 bit credit, multi- currency / language features, negative vend, 
and / or data entry). 

Z3-Z4 : Country / Currency Code - packed BCD. 

The packed BCD country / currency code of the reader can be sent in two different forms depending on the value of the 
left most BCD digit. 

If the left most digit is a 0, the International Telephone Code is used to indicate the country that the reader is set -up for. 
For example, the USA code is 00 01 H (Z3 = 00 and Z4 = 01). 

If the left most digit is a 1, the latest version of the ISO 4217 numeric currency 
code is used (see Appendix Al). For example, the code for the US dollar is 18 
40H (Z2 = 18 and Z3 = 40) and for the Euro is 1978 (Z3 = 19 and Z4 = 78). Use 
FFFFh if the country code in unknown. 



Zl : 
Z2 : 
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For level 3 cashless devices, it is mandatory to use the ISO 4217 numeric 
currency code (see Appendix Al). 

Z5 : Scale Factor. 

The multiplier used to scale all monetary values transferred between the VMC 
and the reader. 

Z6 : Decimal Places. 

The number of decimal places used to communicate monetary values between the 
VMC and the payment media reader. 

All pricing information sent between the VMC and the payment media reader is 
scaled using the scale factor and decimal places. This corresponds to: 

ActualPrice = PX-10" Y 

where P is the scaled value send in the price bytes, and X is the scale factor, and 
Y is the number of decimal places. For example if there are 2 decimal places and 
the scale factor is 5, then a scaled price of 7 will mean an actual of 0.35. 

Z7 : Application Maximum Response Time - seconds. 

The maximum length of time a reader will require to provide a response to any 
command from the VMC. The value reported here supercedes the payment 
reader's default NON-RESPONSE time defined in section 7.5 if the value 
reported here is greater. 

Z8 : Miscellaneous Options - xxxxyyyy 

xxxx: Unused (must be set to 0) 
yyyy: Option bits 

b0=0: The payment media reader is NOT capable of restoring funds to the 
user's payment media or account. Do not request refunds. 

b0=l: The payment media reader is capable of restoring funds to the user's 
payment media or account. Refunds may be requested. 

bl=0: The payment media reader is NOT multivend capable. 

Terminate session after each vend. 
bl=l: The payment media reader is multivend capable. Multiple items may 
be purchased within a single session. 

b2=0: The payment media reader does NOT have a display. 
b2=l: The payment media reader does have its own display. 

b3=0: The payment media reader does NOT support the VEND/CASH 

SALE subcommand. 
b3=l: The payment media reader does support the VEND/CASH SALE 

subcommand. 

b4-b7=0 Any future options must be covered by the EXPANSION 
COMMAND option bits. 
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7.4.3 SETUP - Max / Min Prices 





Max / Min 


Maximum 


Minimum 


SETUP 


Prices 


Price 


Price 


(11H/61H) 


(01H) 








Yl 


Y2-Y3 


Y4-Y5 



Level 01 / 02 / 03 Readers 

Yl : Max / Min prices 

Indicates the VMC is sending the price range to the reader. 

Y2 - Y3 : Maximum Price - scaled 

This information should be sent as soon as the VMC prices have been 
established and any time there is a change in the maximum price, If the VMC 
does not know the maximum price, FFFFh should be sent. 

Y4 - Y5 : Minimum Price - scaled 

This information should be sent as soon as the VMC prices have been 
established and any time there is a change in the minimum price. If the VMC 
does not know the minimum price, OOOOh should be sent. 



SETUP 
(11H/61H) 


Max/ 
MinPrices 
(01H) 
Yl 


Maximum 

Price 

Y2-Y5 


Minimum 

Price 

Y6-Y9 


Currency 

Code 

YlO-Yll 


Level 03 (E> 


CPANDED CURRENCY 


MODE) Readers 



Yl : Max / Min prices 

Indicates the VMC is sending the price range to the reader. 

Y2 - Y5 : Maximum Price - scaled 

This information should be sent as soon as the VMC prices have been 
established and any time there is a change in the maximum price, If the VMC 
does not know the maximum price, FFFFFFFFh should be sent. 

Y6 -Y9 : Minimum Price - scaled 

This information should be sent as soon as the VMC prices have been 
established and any time there is a change in the minimum price. If the VMC 
does not know the minimum price, OOOOOOOOh should be sent. 

YlO-Yll Currency Code 

The currency code used during this command per ISO 4217 (see Appendix Al). 
The value is configured as packed BCD with the leading digit a 1 (one). For 
example, the code for the US dollar would be 1840 (Z10 = 18 and Zl 1 = 40). 
and for the Euro is 1978 (Z10 = 19 and Zl 1 = 78). 



Reader response: 
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No Data response 



7.4.4 POLL 



POLL 

(12H / 62H) 



The POLL command is used by the VMC to obtain information from the payment media reader. 
This information may include user actions (CANCEL SESSION REQUEST), hardware 
malfunctions (MALFUNCTION /ERROR), software malfunctions (COMMAND OUT OF 
SEQUENCE) or information explicitly requested by the controller (READER 
CONFIGURATION DATA). An ACK response indicates that no error states exist, and either no 
information request is pending or pending information is not yet ready for transmission. 

In addition to an ACK, the VMC may receive the following POLL responses from the payment 
media reader. 
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Reader responses: 




Zl 



JUST RESET 

Indicates the payment media reader has been reset. 

Note: the difference between ACK and JUST RESET responses is: 

00H 00H* =JUST RESET 

00H* =ACK 

*mode bit=l 



Reader 


Reader 


Country 


Country 


Scale 


Decimal 


Application 


Miscellaneous 


Config 


Feature 


Code 


Code 


Factor 


Places 


Maximum 


Options 


Info 


Level 


High 


Low 






Response 




(01H) 












Time 




Zl 


Z2 


Z3 


Z4 


75 


Z6 


Z7 


Z8 



See paragraph 7.4.2 for a detailed explanation of this response. 



Display 


Display 


Display 


Request 


Time 


Data 


(02H) 






Zl 


Z2 


Z3-Z34 



Zl : DISPLAY REQUEST 

The payment media reader is requesting a message to be displayed on the 
VMC's display. 

Z2 : Display Time - 0.1 second units 

The requested display time. Either the VMC or the payment media reader may 
overwrite the message before the time has expired. 

Z3-Z34 : Display Data - ASCII 

The message to be displayed. Formatting (leading and/or trailing blanks) is the 
responsibility of the payment media reader. 



The number of bytes must equal the product of Y3 and Y4 up to a maximum of 
32 bytes in the setup/configuration command. 
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Begin 


Funds 


Session 


Available 


(03H) 




Zl 


Z2-Z3 



Level 01 

Zl 



Readers 



BEGIN SESSION (level 01 readers) 

Allow a patron to make a selection, but do not dispense product until funds are 
approved. 

Z2-Z3 : Funds Available - scaled 

a. Lesser of the user's payment media or account balance or 
FFFEh units. 

b. Not yet determined - FFFFh. 



Begin 
Session 
(03H) 
Zl 


Funds 
Available 

Z2-Z3 


Payment 
media ID 

Z4-Z7 


Payment 
Type 

Z8 


Payment 
Data 

Z9-Z10 


Level 02 / 


03 Readers 



Zl : BEGIN SESSION (level 02/03 readers ) 

Allow a patron to make a selection, but do not dispense product until funds are 
approved. 

Z2-Z3 : Funds Available - scaled 

a. Lesser of the user's payment media or account balance or 
FFFEh units. 

b. Not yet determined - FFFFh. 

Z4-Z7 : Payment media ID. 

00000000h-FFFFFFFEh=Payment media identification number. FFFFFFFFh 
= unknown payment media ID. 

Z8 : Type of payment: 

OOxxxxxxb = normal vend card (refer EVA-DTS Standard, Appendix 

A. 1.1 Definitions) 
xlxxxxxxb = test media 
lxxxxxxxb = free vend card 
xxOOOOOOb -0 VMC default prices. 

xxOOOOOlb -1 User Group (Z9 = EVA-DTS Element DA701) 

Price list number (Z10 = EVA-DTS Element LA101)* 

xxOOOOlOb -2 User Group (Z9 = EVA-DTS Element DA701) 

Discount group index (Z10 = EVA-DTS Element MA403) 

xxOOOOl lb -3 Discount percentage factor (Z9=00, Z10 = to 100**, 
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report as positive value in EVA-DTS Element MA404) 
xxOOOlOOb -4 Surcharge percentage factor (Z9=00, Z10 = to 100**, 
report as negative value in EVA-DTS Element MA404) 

* User Group is a segmentation of all authorized users. It allows 
selective cost allocation. A User Group usually has no direct 
relation to a price list. 

Price Lists are tables of prices. Each Price List contains an 
individual price for each product. 

Discount Group indicates the Price List on which the Percentage 
Factor will be applied. 

If the User Group, the Price List or Discount Group is unknown 
by the VMC, the normal prices are used (Z8 is defaulted to OOh). 

Minimum value for Z9 and Z10 is 0. 

** Percentages are expressed in binary (00 to 64h) 

Note: 

These functions may NOT be supported by all VMCs. 
Z9-Z10 : Payment data as defined above. 



Begin 


Funds 


Payment 


Payment 


Payment 


User 


User 


Card 


Session 


Available 


media ID 


Type 


Data 


Language 


Currency 


Options 


(03H) 












Code 




Zl 


72-75 


Z6-Z9 


Z10 


Z11-Z12 


Z13-Z14 


Z15-Z16 


Z17 



Level 03 (EXPANDED CURRENCY MOD 



E) Readers 



Zl : BEGIN SESSION (level 03 readers / EXPANDED CURRENCY MODE) 

Allow a patron to make a selection, but do not dispense product until funds are 
approved. 

Z2-Z5 : Funds Available - scaled 

a. Lesser of the user's payment media or account balance or 
FFFFFFFEh units. 

b. Not yet determined - FFFFFFFFh. 

Z6-Z9 : Payment media ID. 

00000000h-FFFFFFFEh=Payment media identification number. FFFFFFFFh 
= unknown payment media ID. 
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Z10 



Type of payment: 

OOxxxxxxb = normal vend card (refer EVA-DTS Standard, Appendix 

A. 1.1 Definitions) 
xlxxxxxxb = test media 
lxxxxxxxb = free vend card 
xxOOOOOOb -0 VMC default prices. 

xxOOOOOlb - 1 User Group (Zl 1 = EVA-DTS Element DA701) 

Price list number (Z12 = EVA-DTS Element LA101)* 
xxOOOOlOb -2 User Group (Zl 1 = EVA-DTS Element DA701) 

Discount group index (Z12 = EVA-DTS Element MA403) 
xxOOOOl lb -3 Discount percentage factor (Zl 1=00, Z12 = to 100**, 

report as positive value in EVA-DTS Element MA404) 
xxOOOlOOb -4 Surcharge percentage factor (Zl 1=00, Z12 = to 100**, 

report as negative value in EVA-DTS Element MA404) 

* User Group is a segmentation of all authorized users. It allows 
selective cost allocation. A User Group usually has no direct 
relation to a price list. 

Price Lists are tables of prices. Each Price List contains an 
individual price for each product. 

Discount Group indicates the Price List on which the Percentage 
Factor will be applied. 

If the User Group, the Price List or Discount Group is unknown 
by the VMC, the normal prices are used (Z10 is defaulted to 
OOh). 

Minimum value for Zll and Z12 is 0. 

** Percentages are expressed in binary (00 to 64h) 



Note: 

These functions may NOT be supported by all VMCs. 
Z11-Z12: Payment data as defined above. 

Z13-Z14 User language to use during this session (2 ASCII characters per ISO 639:latest 
version). The user language is read from the patrons card and, if supported, 
should be used instead of the VMC default language (taken according to the 
setup command International Telephone code) up to the next "session 
complete". If the VMC is not able to support this language, the default setting 
should be used. 

Z15-Z16 User currency code to use during this session per ISO 4217 (see Appendix Al). 

The value is configured as packed BCD with the leading digit a 1 (one). For 
example, the code for the US dollar would be 1840 (Z15 = 18 and Z16 = 40). 
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and for the Euro is 1978 (Z6 = 19 and Z7 = 78). 

Z17 Card options (overrides any previous default settings for reader) 

b0=0: The VMC displays the credit if it is programmed to do so 
bO=l: The VMC must not display the credit (privacy purpose - user 
option) 

bl=0: The actual inserted patrons card has no refund capability 

bl=l: The actual inserted patrons card has refund capability (Note: a reader 

with refund capability may be used with both type of cards) 
b2=0 The actual inserted patrons card has no revalue capability 
b2=l The actual inserted patrons card has revalue & negative vend 

capability 

b3-b7: Reserved for future extensions (unused bits must be set to 0) 

Refund means the ability to put money back on the inserted patrons card up to the 
value of the last transaction Revalue means the ability to put money back on the 
inserted patrons card up to any value. 

The card reader will define the currency type at the beginning of each card session. 
The currency type will be used for all following transactions in that session. If 
the VMC does not support this currency type, it will end the session. 



Session 

Cancel Request 

(04H) 

Zl 



Zl : SESSION CANCEL REQUEST 

The payment media reader is requesting the VMC to cancel the session. The VMC 
should initiate an eventual SESSION COMPLETE. This response is sent to the 
VMC whenever the payment media is removed or a request for removal from the 
reader is made by the user (e.g. if a return button on the reader is pressed). 



Vend 


Vend 


Approved 


Amount 


(05H) 




Zl 


Z2-Z3 



Level 01 / 02 / 03 Readers 

Refer to paragraph 7.4.5 for detailed explanation. 



Vend 


Vend 


Approved 


Amount 


(05H) 
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Zl 


72-75 


D CURRENCY MODE) Readers 


Level 03 (EXPANDE 



Refer to paragraph 7.4.5 for detailed explanation. 




Refer to paragraph 7.4.5 for detailed explanation. 



End 

Session 

(07H) 

Zl 



Refer to paragraph 7.4.9 for detailed explanation. 



Cancelled 

(08H) 
Zl 



Refer to paragraph 7.4.14 for detailed explanation. 



Peripheral 


Manufacturer 


Serial 


Model 


Software 


ID 


Code 


Number 


Number 


Version 


(09H) 










Zl 


Z2-Z4 


Z5-Z16 


Z17-Z28 


Z29-Z30 



Level 01 / 02 / 03 Readers (If VMC indicates Level 01 or 02) 



Zl : PERIPHERAL ID 

Reader is sending peripheral ID information. 

Z2 - Z4 : Manufacturer Code - ASCII 

Identification code for the equipment supplier. Currently defined codes are 
listed in the EVA document entitled "European Vending Association Data 
Transfer Standard" (EVA-DTS), the Audit Data Lists section, sub-section 2, 
"Manufacturer Codes". 

Z5-Z16 : Serial Number - ASCII 

Factory assigned serial number. 

Z17-Z28 : Model Number - ASCII 
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Manufacturer assigned model number. 

Z29-Z30 : Software Version - packed BCD 
Current software version. 



Peripheral 
ID 

(09H) 
Zl 


Manufacturer 
Code 

Z2-Z4 


Serial 
Number 

Z5-Z16 


Model 
Number 

Z17-Z28 


Software 
Version 

Z29-Z30 


Optional 
Feature bits 

Z31 - Z34 


Level 03 Readers (If VM< 


2 indicates Level 03] 





Zl : PERIPHERAL ID 

Reader is sending peripheral ID information. 

Z2 - Z4 : Manufacturer Code - ASCII 

Identification code for the equipment supplier. Currently defined codes are 
listed in the EVA document entitled 'European Vending Association Data 
Transfer Standard" (EVA-DTS), the Audit Data 
Lists section, sub- section 2, "Manufacturer Codes". 

Z5-Z16 : Serial Number - ASCII 

Factory assigned serial number. 

Z17-Z28 : Model Number - ASCII 

Manufacturer assigned model number. 

Z29-Z30 : Software Version - packed BCD 
Current software version. 

Z31- Z34 Optional Feature Bits. Each of the 32 bits indicate an optional feature 

availability. Bits should be sent in descending order, Le. bit 31 is sent first and 
bit is sent last. Options must be enabled by the VMC using the Expansion 
Optional Feature Bit Enable (17H-04H) command and all features are 
disabled after a reset. Currently defined options are: 

bO - File Transport Layer supported 

bl - = 16 bit monetary format, 1 = 32 bit monetary format 
b2 - multi currency / multi lingual 
b3 - negative vend 
b4 - data entry 

b5 to b31 not used (should be set to 0) 

Note: If 32 bit monetary format (bl) and or multi currency / multi lingual 
(b2) options are enabled, this condition will be known as EXPANDED 
CURRENCY MODE in the rest of the document. 
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Malfunction / Error 


Error Code 


(OAH) 




Zl 


Z2 



Zl : MALFUNCTION/ERROR 

The payment media reader is reporting a malfunction or error. 

Z2 : Error Code - xxxxyyyy 



xxxx error types 

0000: Payment media Error 1 

0001: Invalid Payment medial 

0010: Tamper Error 1 

00 1 1 : Manufacturer Defined Error 1 

0100: Communications Error2 

0101: Reader Requires Servic e2 

0110: Unassigned2 

0111: Manufacturer Defined Error2 

1000: Reader Failure3 

1001: Communications Error3 

1010: Payment media Jammed3 

1011: Manufacturer Defined Error 

1 100: Refund error - internal reader credit lost 



1101-1111: Unassigned 

1 Transient error - Reported once 

2 Non- transient error - Reported every POLL until cleared. Reader still 
functional. 

3 Non- transient error - Reported every POLL until cleared. Reader not presently 
functional. 

yyyy = Manufacturer defined subcode 



Transient Error Handling 

The error will be reported to the VMC until it has been ACKnowledged. The error state 
will be cleared in the reader, and normal operations will continue. 

Non-transient Error Handling 

The error will be reported to the VMC at each POLL as long as it exists. If the reader is 
still functional, multi- message responses will allow normal responses in addition to the 
error report. 
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Note : Refund error is sent from the media reader when it is not able to refund money to the 
payment media following a failed or cancelled vend. The reader internally cancels the credit and 
the credit is lost. 



Command 
Out of 
Sequence 
(OBH) 

Zl 

Level 01 Readers 

Zl : COMMAND OUT OF SEQUENCE (Level 01 readers) 

The payment media reader has received a command that is not executable in its 
current state, or that violates one of the uninterruptable sequences. The offending 
command should be ACKed but not acted upon the reader. The VMC will send 
the RESET command to the reader upon reception of this response. Note that the 
reader will continue with any credit update process prior to resetting. 



Command 


Status 


Out of 




Sequence 




(OBH) 




Zl 


Z2 


Level 02 / 03 Readers 



Zl : COMMAND OUT OF SEQUENCE. (Level 02/03 readers) 

The payment media reader has received a command that is not executable in its 
current state, or that violates one of the uninterruptable sequences. The offending 
command should be ACKed but not acted upon the reader. The VMC will send 
the RESET command to the reader upon reception of this response. Note that the 
reader will continue with any credit update process prior to resetting. 

Z2 : Status 

The state of the payment media reader. 
01: Inactive state 
02: Disabled state 
03: Enabled state 
04: Session idle state 
05: Vend state 
06: Revalue state 
07: Negative Vend state 



Revalue 
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Approved 

(ODH) 

Zl 



Level 02 / 03 Readers 

Refer to paragraph 7.4.16 for detailed explanation. 



Revalue 
Denied 
(OEH) 
Zl 



Level 02 / 03 Readers 



Refer to paragraph 7.4.16 for detailed explanation. 



Revalue 


Revalue 


Limit Amount 


Limit Amount 


(OFH) 




Zl 


Z2-Z3 



Level 02 / 03 Readers 

Refer to paragraph 7.4.17 for detailed explanation. 
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Revalue 


Revalue 


Limit Amount 


Limit Amount 


(OFH) 




Zl 


72-75 


Level 03 (EXPANDED CURR 



Refer to paragraph 7.4.17 for detailed explanation. 



User 


Number 


Length 


User 


File Data 


of User File 


Of User File 


Data 


(10H) 








Zl 


Z2 


Z3 


Z4-Zn 



Level 02 Readers 

Obsolete Response - Do not use for new designs! ! (Use EXPANSION - Diagnostics) 
Refer to paragraph 7.4.19 for detailed explanation. 



Time/Date 
Request 
(11H) 
Zl 



Level 02 / 03 Readers 



Zl 



TIME DATE REQUEST 

In certain circumstances it will be necessary to synchronize the real time clock 
of the card reader with real time clock of the VMC. The card reader will 
respond with TIME/DATE REQUEST to a POLL command of the VMC. The 
VMC will follow with the EXPANSION- WRITE TIME/DATE FILE to the 
card reader. Refer to paragraph 7.4.19. 
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Data Entry 


Data Entry Length 


Request Response 


and Repeat Bit 


(12H) 


Z2 


Zl 





Level 03 Readers (if Data Entry option enabled) 



Zl : DATA ENTRY REQUEST 

The reader is making a DATA ENTRY REQUEST. 

Z2 : DATA ENTRY LENGTH and REPEAT BIT 
rnnnnnnnn 

r - Repeat Bit (0 = initial request / 1 = repeated requests 
nnnnnnn - number of requested characters / keys 

Depending on the type of data being entered, it is a higher level system decision on whether or 
not the data is displayed on either the vending machine or card reader. If the data is not 
displayed (a recommendation for certain types of sensitive data) the vending machine or card 
reader display can still be optionally used to indicate a prompt and/or representation of the data 
entered for user feedback (i.e., asterisks *****). 

If the card reader uses the vending machine's display for Data Entry information, it must 
concatenate the DATA ENTRY REQUEST Response (12H) with the DISPLAY REQUEST 
response (02H). Upon receipt of the response pair, the vending machine controller will give its 
display to the card reader for the duration of the Data Entry session plus the amount of time 
specified in the Z2 Display Time following the end of the session (regardless of a normal or 
cancelled session). In essence, the vending machine controller will not write anything to its 
display during the Data Entry session plus the Z2 time. The reader will be able to update the 
Data Entry information on the vending machine's display by sending additional DISPLAY 
REQUEST responses during the Data Entry session. 

Please see additional DATA ENTRY procedures in Section 7.4.15. 



Data Entry 

Cancel 

(13H) 

Zl 

Level 03 Readers (if Data Entry option enabled) 

Zl : DATA ENTRY CANCEL 

The user has pushed the reader's RETURN button before completing the DATA 

ENTRY. The VMC should terminate all DATA ENTRY activity in progress. 
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FTL 

REQ TO RCV 

(1BH) 

Zl 



Level 03 Readers (if File Transport Layer option enabled) 

Zl : FTL REQ TO RCV 

The reader is requesting to receive data from a device or VMC. 

Z2 : FTL Destination Address 

The destination address of the response as defined in Section 2.6. 

Z3 : FTL Source Address (Reader = 10H / 60H) 

The source address of the response as defined in Section 2.6. 

Z4 : FTL File ID 

The type of information desired as defined in Section 2.6. 

Z5 : FTL Maximum Length 

The total number of blocks in the file as defined in Section 2.6. 

Z6 : FTL Control 

Data transfer control information as defined in Section 2.6. 



FTL 

RETRY/DENY 

(1CH) 

Zl 



Level 03 Readers (if File Transport Layer option enabled) 

Zl : FTL RETRY / DENY 

The reader is requesting a device or VMC to retry or deny the last FTL 
command. 

Z2 : FTL Destination Address 

The destination address of the response as defined in Section 2.6. 

Z3 : FTL Source Address (Reader = 10H / 60H) 

The source address of the response as defined in Section 2.6. 

Z4 : FTL Retry Delay 

The retry delay as defined in Section 2.6. 
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Level 03 Readers (if File Transport Layer option enabled) 



Zl : FTL SEND BLOCK 

The reader is sending a block of data (maximum of 31 bytes) to a device or 
VMC. 

Z2 : FTL Destination Address 

The destination address of the response as defined in Section 2.6. 

Z3 : FTL Block # 

The sequential number of the block as defined in Section 2.6. 

Z4- Z34 FTL Data (maximum of 3 1 bytes) 

: The actual data portion of the block as defined in Section 2.6. 



FTL 

OK TO SEND 

(1EH) 

Zl 



Level 03 Readers (if File Transport Layer option enabled) 



Zl : FTL OK TO SEND 

The reader is indicating that it is OK for the device or VMC to send it data. 

Z2 : FTL Destination Address 

The destination address of the response as defined in Section 2.6. 

Z3 : FTL Source Address (Reader = 10H / 60H) 

The source address of the response as defined in Section 2.6. 
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FTL 
REQ TO 
SEND 
(1FH) 

Zl 

Level 03 Readers (if File Transport Layer option enabled) 

Zl : FTL REQ TO SEND 

The reader is requesting to send data to a device or VMC. 

Z2 : FTL Destination Address 

The destination address of the response as defined in Section 2.6. 

Z3 : FTL Source Address (Reader = 10H / 60H) 

The source address of the response as defined in Section 2.6. 

Z4 : FTL File ID 

The type of information desired as defined in Section 2.6. 

Z5 : FTL Maximum Length 

The total number of blocks in the file as defined in Section 2.6. 

Z6 : FTL Control 

Data transfer control information as defined in Section 2.6. 



Diagnostics 


User 


Response 


Defined 


(FFH) 


Data 


Zl 


Z2-Zn 



Refer to paragraph 7.4.28 for detailed explanation. 



7.4.5 VEND - Request 





Vend 


Item 


Item 


Vend 


Request 


Price 


Number 


(13H/63H) 


(00H) 








Yl 


Y2-Y3 


Y4-Y5 



Level 01 / 02 / 03 Readers 



Yl : VEND REQUEST 

The patron has made a selection. The VMC is requesting vend approval from the 
payment media reader before dispens ing the product. 

Y2- Y3 : Item Price - scaled 

The price of the selected product. 
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Y4- Y5 : Item Number 

The item number of the selected product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 



Reader response: 



Vend 


Vend 


Approved 


Amount 


(05H) 




Zl 


Z2-Z3 



Zl : VEND APPROVED 

Allow the selected product to be dispensed. 

Z2-Z3 : Vend Amount - scaled 

This is the amount deducted from the user's payment media or account. This may 
not match the amount specified in the VEND REQUEST command; it may be 
surcharged or discounted. 
FFFFh - an electronic token was used. 




NOTE: The VMC must use Vend Amount to update the credit on the 

screen. The Reader must fill this field with the used amount for the 
transaction. 



Zl : VEND DENIED 

Approval denied for the patron's selection. Do not dispense any products. 





Vend 


Item 


Item 


Vend 


Request 


Price 


Number 


(13H/63H) 


(00H) 








Yl 


Y2-Y5 


Y6-Y7 



Level 03 (EXPANDED CURRENCY MODE) Readers 



Yl : VEND REQUEST 

The patron has made a selection. The VMC is requesting vend approval from the 
payment media reader before dispensing the product. 

Y2- Y5 : Item Price - scaled 

The price of the selected product. 

Y6- Y7 : Item Number 

The item number of the selected product. This number is defined by the 
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manufacturer, and set to FFFFh for undefined or not implemented. 



Reader Response: 



Vend 


Vend 


Approved 


Amount 


(05H) 




Zl 


72-75 



Level 03 (EXPANDED CURRENCY MODE) Readers 

Zl : VEND APPROVED 

Allow the selected product to be dispensed. 

Z2-Z5 : Vend Amount - scaled 

This is the amount deducted from the user's payment media or account. This may 
not match the amount specified in the VEND REQUEST command; it may be 
surcharged or discounted. 
FFFFFFFFh - an electronic token was used. 

NOTE: The VMC must use Vend Amount to update the credit on the 

screen. The Reader must fill this field with the used amount for the 
transaction. 
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7.4.6 VEND -Cancel 





Vend 


Vend 


Cancel 


(13H/63H) 


(01H) 




Yl 



Yl : VEND CANCEL 

This command can be issued by the VMC to cancel a VEND REQUEST 
command before a VEND APPROVED/DENIED has been sent by the payment 
media reader. The payment media reader will respond to VEND CANCEL with a 
VEND DENIED and return to the Session Idle state. 



Reader response: 



Vend 
Denied 
(06H) 
Zl 



See paragraph 7.4.5 for explanation. 



7.4.7 VEND - Success 





Vend 


Item 


Vend 


Success 


Number 


(13H/63H) 


(02H) 






Yl 


Y2-Y3 



Yl : VEND SUCCESS 

The selected product has been successfully dispensed. 

Y2-Y3 : Item number 

The item number of the selected product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 

NOTE A reset between VEND APPROVED and VEND SUCCESS shall be 
interpreted as a VEND SUCCESS. 



Reader response: 

No Data response 
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7.4.8 VEND -Failure 





Vend 


Vend 


Failure 


(13H/63H) 


(03H) 




Yl 



Yl : VEND FAILURE 

A vend has been attempted at the VMC but a problem has been detected and the 
vend has failed. The product was not dispensed. Funds should be refunded to 
user's account. 

Reader response: 

No Data response 



Vend failure sequence 

In order to ensure that a reader refunds after a Vend Failure command, the VMC 
must send at least a single Poll command to obtain the reader possible answers: 



ACK 


Refund Complete 


MALFUNCTION ERROR 
code HOOyyyy 


Refund error- internal reader credit lost 


SILENCE 


Refund in progress. VMC must repoll reader until ACK or 
Malfunction error answer for maximum NON Response time. 



7.4.9 SESSION COMPLETE 





Session 


Vend 


Complete 


(13H/63H) 


(04H) 




Yl 



Yl : SESSION COMPLETE 

This tells the payment media reader that the session is complete and to return to 
the Enabled state. SESSION COMPLETE is part of a command/response 
sequence that requires an END SESSION response from the reader. 

Reader response: 



End 

Session 

(07H) 

Zl 



Zl : END SESSION 

This command is issued in response to a SESSION COMPLETE command. The 
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END SESSION response indicates the reader has returned to the Enabled state. If 
"END SESSION" is not received by the VMC within a the maximum application 
non-response time, the VMC must issue a "RESET" command. 



7.4.10 CASH SALE 





Cash 


Item 


Item 


Vend 


Sale 


Price 


Number 


(13H/63H) 


(05H) 








Yl 


Y2-Y3 


Y4-Y5 



Level 01 / 02 / 03 Readers 



Yl : CASH SALE 

A cash sale (cash only or cash and cashless) has been successfully completed by 
the VMC. 

Y2- Y3 : Item Price - scaled 

The price of the selected product or cash portion of the price. 

Y4- Y5 : Item Number 

The item number of the selected product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 



Note: This command is issued for cash auditing applications and is sent to the payment media 
reader if the SETUP/CONFIGURATION bit (b3) is enabled anytime a valid cash transaction is 
completed via a coin mechanism or bill validator. 



Reader response: 

No Data response 





Cash 


Item 


Item ! 


[tern 


Vend 


Sale 


Price 


Number 


Currency 


(13H) 


(05H) 










Yl 


Y2-Y5 


Y6-Y7 i 


Y8-Y9 



Level 03 (EXPANDED CURRENCY MODE) Readers 

CASH SALE 

A cash sale (cash only or cash and cashless) has been successfully completed by 
the VMC. 



MDB/ICP Version 3.0 



March 26, 2003 



82 



Multi-Drop Bus / Internal Communication Protocol 




Y2- Y5 : Item Price - scaled 

The price of the selected product or cash portion of the price. 

Y6- Y7 : Item Number 

The item number of the selected product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 

Y8- Y9 : Item Currency 

The currency for the item price used during the vend. This value may be 
converted within the reader to the readers balancing currency. The item currency 
is sent using the numeric code as defined in ISO 4217 (see Appendix Al). The 
value is configured as packed BCD with the leading digit a 1 (one). For example, 
the code for the US dollar would be 1840 (Z10 = 18 and Zll = 40). and for the 
Euro is 1978 (Z10 = 19 and Zll = 78). 

Note: This command is issued for cash auditing applications and is sent to the payment media 

reader if the SETUP/CONFIGURATION bit (b3) is enabled anytime a valid cash transaction is 

completed via a coin mechanism or bill validator. 



Reader response: 

No Data response 



7.4.11 Negative Vend Request 





Neg.Vend 


Item 


Item 


Vend 


Request 


Value 


Number 


(13H/63H) 


(06H) 








Yl 


Y2-Y3 


Y4-Y5 



Level 03 Reader 



Yl : NEGATIVE VEND REQUEST 

The patron has inserted an item. The VMC is requesting negative vend approval 
from the payment media reader before accepting the returned product. 

Y2- Y3 : Item value - scaled 

The value of the inserted product (16 Bit). 

Y4- Y5 : Item Number 

The item number of the inserted product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 
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Reader response: 



Vend 


Vend 


Approved 


Amount 


(05H) 




Zl 


72-73 



Level 03 (EXPANDED CURRENCY MODE disabled) Readers 



Zl : VEND APPROVED 

Allow the returned product to be accepted, i.e. this means, the reader will be able 
to credit the value to the patrons card, when a vend success will follow the 
approved. 

Z2-Z3 : Vend Amount - scaled 

This is the amount of credit, which will be added to the user's payment media or 
account. This may not match the amount specified in the NEGATIVE VEND 
REQUEST command; it may be surcharged or discounted. 
FFFFh - an electronic token will be credited. 





Neg.Vend 


Item 


Item 


Vend 


Request 


Value 


Number 


(13H/63H) 


(06H) 








Yl 


Y2-Y5 


Y6-Y7 



Level 03 (EXPANDED CURRENCY MODE) Readers 



Yl : NEGATIVE VEND REQUEST 

The patron has inserted an item. The VMC is requesting negative vend approval 
from the payment media reader before accepting the returned product. 

Y2- Y5 : Item value - scaled 

The value of the inserted product. 

Y6- Y7 : Item Number 

The item number of the inserted product. This number is defined by the 
manufacturer, and set to FFFFh for undefined or not implemented. 



Reader response: 
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Vend 


Vend 


Approved 


Amount 


(05H) 




Zl 


Z2-Z5 



Level 03 (EXPANDED CURRENCY MODE) Readers 

Zl : VEND APPROVED 

Allow the returned product to be accepted, i.e. this means, the reader will be able 
to credit the value to the patrons card, when a vend success will follow the 
approved. 

Z2-Z5 : Vend Amount - scaled 

This is the amount of credit, which will be added to the user' s payment media or 

account. This may not match the amount specified in the NEGATIVE VEND 

REQUEST command; it may be surcharged or discounted. 

FFFFFFFFh - an electronic token will be credited. 



Vend 
Denied 
(06H) 
Zl 



Zl : VEND DENIED 

Approval denied for the returned product. Do not accept the product or return it if 
possible. 

Note: This command is used in the uninterruptable vend sequence like the normal REQUEST 
VEND and is followed by the normal responses VEND APPROVED or VEND DENIED, for the 
reader to confirm the credit update possibility and the final VEND SUCCESS or VEND 
FAILURE command to update the patron's credit. 



Designers of cashless devices must pay special attention in implementing this command, 
especially for non locking readers. Credit should only be generated on the media upon final 
reception of VEND SUCCESS to avoid unwanted credit in the system. 
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Designers of both the VMC and the readers have to deal with fault conditions of such a system 
carefully. A normal sequence description is added to the example vend sessions with hints to 
different application features. 



MDB/ICP Version 3.0 



March 26, 2003 



86 



Multi-Drop Bus / Internal Communication Protocol 




7.4.12 READER -Disable 



Reader 


Disable 


(14H/64H) 


(00H) 




Yl 



Yl : READER DISABLE 

This informs the payment media reader that it has been disabled, i.e. it should no 
longer accept a patron's payment media for the purpose of vending. Vending 
activities may be re-enabled using the READER ENABLE command. The 
payment media reader should retain all SETUP information. 

NOTE Any transaction in progress will not be affected and should continue to its normal 
completion. 

Reader response: 

No Data response 



7.4.13 READER -Enable 



Reader 


Enable 


(14H/64H) 


(01H) 




Yl 



Yl : READER ENABLE 

This informs the payment media reader that is has been enabled, i.e. it should 
now accept a patron's payment media for vending purposes. This command must 
be issued to a reader in the Disabled state to enable vending operations. 

Reader response: 

No Data response 
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7.4.14 READER -Cancel 



Reader 


Cancel 


(14H/64H) 


(02H) 




Yl 



Yl : READER CANCEL 

This command is issued to abort payment media reader activities which occur in 
the Enabled state. It is the first part of a command/response sequence which 
requires a CANCELLED response from the reader. 

Reader response: 



Cancelled 

(08H) 

Zl 



Zl : CANCELLED 

This is the reader's response to the READER CANCEL command from the 
VMC. This command comprises a command/response sequence. Its use is only 
appropriate in the Enabled state. 

7.4.15 DATA ENTRY - Response (Key Entries) 

The purpose of the overall Data Entry request / response sequence is to allow the machine user to 
enter data (i.e., a card validation number) using the selection buttons on the vending machine. 



The DATA ENTRY request / response sequence can occur in the Enabled state only. It is 
the responsibility of the reader to enforce this rule. 



Depending on the type of data being entered, it is a higher level system decision on whether or 
not the data is displayed on either the vending machine or card reader. If the data is not 
displayed (a recommendation for certain types of sensitive data) the vending machine or card 
reader display can still be optionally used to indicate a prompt and/or representation of the data 
entered for user feedback (i.e., asterisks *****). Please see additional information on the 
vending machine's display usage for Data Entry in the DATA ENTRY REQUEST 
Response (12H) description in the 7.4.4 POLL section. 

The DATA ENTRY RESPONSE key entries are sent to the reader as they are pressed. 
Depending on the user's speed of entry and vending machine controller cycle time, the data may 
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be sent either as a digit at a time, a sub group of digits, or the entire length of digits as specified 
in the Z2 Data Entry Length byte in the DATA ENTRY REQUEST response. For example, if 
the Data Entry Length is 6 digits, but only 2 are initially (and quickly) entered, the vending 
machine controller will send the 2 that are available via the DATA ENTRY RESPONSE Y2-Y9 
command. The balance will be sent via other DATA ENTRY RESPONSE Y2-Y9 commands 
when available. 



It is up to the reader to merge the received DATA ENTRY RESPONSE data and optionally 
update the display as required. The session is ended after the VMC sends the final DATA 
ENTRY RESPONSE data (no SESSION COMPLETE command is required). Note that the 
VMC display will remain available to the reader for the amount of time requested in the previous 
DISPLAY REQUEST response. 

If the data entry process is cancelled by the VMC for any reason, the VMC will send the DATA 
ENTRY RESPONSE with all data bytes (Y2- Y9) set to FFh. This will terminate the DATA 
ENTRY REQUEST and return the reader to the Enabled state. 

For ease of command message processing, the Data Entry Data has been fixed at 8 characters 
(Y2-Y9). Unused bytes must be sent as OOh to pad out the entire command to byte Y9. 





Data Entry 


Data Entry 


Reader 


Response 


Data 


(14H / 64H) 


(03H) 


Y2-Y9 




Yl 





Level 03 Readers (if option enabled) 

Yl : DATA ENTRY RESPONSE 

The VMC is providing a DATA ENTRY RESPONSE to the reader. 

Y2-Y9 : DATA ENTRY DATA 

Data should be in ASCII, one character per byte. Data should be left justified 

(first character / key in Y2, second in Y3, etc.). The number of data bytes must 

equal eight (8) and unused data bytes must be sent as OOh. 



If the data entry process is cancelled by the VMC for any reason, the VMC will 
send this message with all DATA ENTRY data bytes set to FFh. 
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Note: The reader must translate the VMC key information into the 

appropriate key needed for the application 

Reader response: 
No Data response 

Note: If the reader has additional display information to send to the VMC following the 
DATA ENTRY RESPONSE, it should send it via a DISPLAY REQUEST response to 
one of the next POLL commands from the VMC. 
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7.4.16 REVALUE - Request (Level 02 / 03 





Revalue 


Revalue 


Revalue 


Request 


Amount 


(15H/65H) 


(00H) 






Yl 


Y2-Y3 



Level 02 / 03 Readers 

Yl : REVALUE REQUEST (Level 02 Readers) 

A balance in the VMC account because coins or bills were accepted or some 
balance is left after a vend. With this command the VMC tries to transfer the 
balance to the payment media. 

Y2-Y3 : Revalue amount - scaled. 

The revalue amount should not exceed the revalue limit value given by the 
command REVALUE LIMIT REQUEST. 





Revalue 


Revalue 


Revalue 


Request 


Amount 


(15H/65H) 


(00H) 






Yl 


Y2-Y5 



Level 03 (EXPANDED CURRENCY MODE) Readers 

Yl : 



Y2-Y5 



REVALUE REQUEST (Level 03 Readers) 
A balance in the VMC account because coins or bills were accepted or some 
balance is left after a vend. With this command the VMC tries to transfer the 
balance to the payment media. 

Revalue Amount - scaled. 

The revalue amount should not exceed the revalue limit value given by the 
command REVALUE LIMIT REQUEST. 



Reader response: 



Revalue 
Approved 
(0DH) 
Zl 



Level 02 / 03 Readers 



Zl : REVALUE APPROVED (Level 02 / 03 Readers) 

A balance is in the VMC account because coins or bills were accepted or some 
balance is left after a vend. The VMC has issued a REVALUE REQUEST to the 
payment media reader to transfer the balance to the payment media. The payment 
media reader accepted the request and added its value to the payment media 
balance. The reader then responds with a REVALUE APPROVED, so the VMC 
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may clear the account. 



Revalue 
Denied 
(OEH) 

_Z1 

Level 02 Readers 



Zl : REVALUE DENIED (Level 02 / 03 Readers) 

A balance is in the VMC account because coins or bills were accepted or some 
balance is left after a vend. The VMC has issued a REVALUE REQUEST to the 
payment media reader to transfer the balance to the payment media. The payment 
media reader does not accept the request and responds with a REVALUE 
DENIED, so the VMC has to pay out change. It is a quite common situation if 
there is no payment media inserted at this moment. 

7.4.17 REVALUE - Limit Request (Level 02 / 03 





Readers) 




Revalue 


Revalue 


Limit Request 


(15H/65H) 


(01H) 




Yl 



Level 02 / 03 Readers 



Note: If revaluing, follow the BEGIN SESSION with this command. 



Yl : REVALUE LIMIT REQUEST (Level 02 Readers) 

In a configuration with a bill and/or coin acceptor and payment media reader 
connected to a VMC, the VMC must know the maximum amount the payment 
media reader eventually will accept by a REVALUE REQUEST. Especially if 
the bill acceptor accepts a wide range of bills. Otherwise the VMC may be 
confronted by the situation where it accepted a high value bill and is unable to 
pay back cash or revalue it to a payment media, (see also below) 



Reader response: 



Revalue 


Revalue 


Limit 


Limit 


Amount 


Amount 


(0FH) 




Zl 


Z2-Z3 



Level 02 / 03 (EXPANDED CURRENCY MODE disabled) Readers 



Zl : REVALUE LIMIT AMOUNT (Level 02 / 03 Readers) 
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The patron intends to revalue the payment media with a bill of some value. The 
VMC must know what kind of bills to accept, so it will issue a REVALUE 
LIMIT REQUEST to get the amount the payment media reader will accept. The 
payment media reader will respond with the scaled value, calculated with the 
maximum allowed payment media balance minus the current balance of the 
payment media. The payment media reader responds with REVALUE DENIED 
if there is no payment media available upon this request. 

Z2-Z3 : Revalue limit value - scaled. 



Reader response: 



Revalue 


Revalue 


Limit 


Limit 


Amount 


Amount 


(OFH) 




Zl 


72-75 



Level 03 (EXPANDED CURRENCY MODE) Readers 



Zl : REVALUE LIMIT AMOUNT (Level 03 Readers) 

The patron intends to revalue the payment media with a bill of some value. The 
VMC must know what kind of bills to accept, so it will issue a REVALUE 
LIMIT REQUEST to get the amount the payment media reader will accept. The 
payment media reader will respond with the scaled value, calculated with the 
maximum allowed payment media balance minus the current balance of the 
payment media. The payment media reader responds with REVALUE DENIED 
if there is no payment media available upon this request. 

Z2-Z5 : Revalue Limit Value - scaled. 



7.4.18 EXPANSION - Request ID 





Request 


Manufacturer 


Serial 


Model 


Software 


Expansion 


ID 


Code 


Number 


Number 


Version 


(17H/67H) 


(00H) 












Yl 


Y2-Y4 


Y5-Y16 


Y17-Y28 


Y29-Y30 



Yl : REQUEST ID 

The VMC is requesting payment media reader identification information. 
The information included above (Y2- Y30) provides the payment media 
reader with VMC identification information. 

Y2- Y4 : Manufacturer Code - ASCII 

Identification code for the equipment supplier. Currently defined codes are 
listed in the EVA document entitled "The Data Transfer Standard EVA- 
DTS" document, the Audit Data Dictionary section, chapter 4, 
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"Manufacturer Codes". 

Y5- Y16 : Serial Number - ASCII 

Factory assigned serial number. 

Y17- Y28 : Model Number - ASCII 

Manufacturer assigned model number. 

Y29- Y30 : Software Version - packed BCD 
Current software version. 



Reader response: 



Peripheral 


Manufacture 


Serial 


Model 


Software 


ID 


Code 


Number 


Number 


Version 


(09H) 










Zl 


Z2-Z4 


Z5-Z16 


Z17-Z28 


Z29-Z30 



Level 01 / 02 / 03 Readers (If VMC indicates Level 01 or 02) 



Peripheral 
ID 

(09H) 
Zl 


Manufacture 
Code 

Z2-Z4 


Serial 
Number 

Z5-Z16 


Model 
Number 

Z17-Z28 


Software 
Version 

Z29-Z30 


Optional 
Feature Bits 

Z31-Z34 


Level 03 Read 


ers (If VI 


VIC indicates Level 02 


•) 



See paragraph 7.4.4 for a detailed explanation of this response. 



7.4.19 EXPANSION - Read User File (Level 02 Readers) 
Obsolete Command - Do not use for new designs!! (Use EXPANSION - Diagnostics) 





Read 


Number 


Expansion 


User 


of User 


(17H/67H) 


File 


File 




(01H) 






Yl 


Y2 



Level 02 Readers 



Yl= READ USER FILE 

The VMC request's the user file. The length of the file is variable with a 
maximum length of 32 bytes. The contents of the data are defined by the VMC 
manufacturer. If the payment media reader does support this command it will 
respond with USER FILE DATA. 

Y2= Number of User File. 

The File identification number. The number and size of the data files are defined 
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by the payment media reader manufacturer. The maximum number of user files 
are FFh. 



Reader response: 



User 


Number 


Length 


User 


Data 


of User 


of User 


Data 


File 


File 


File 




(10H) 








Zl 


Z2 


Z3 


Z4-Zn 



Zl : USER FILE DATA (only level 02 readers) 

The VMC requires user data and has issued a EXPANSION - READ USER FILE 
to the payment media reader. 

Z2 : Number of User File. 

The File identification number. The number and size of data files are defined by 
the payment media reader manufacturer. The maximum number of user files are 
FFh. 

Z3 : Length of user file 

The length of the user file. The maximum length of the user file is 32 bytes. If the 
user file don't exists the length will be set to OOh. 

Z4-Zn : Data defined by the VMC manufacturer. 

7.4.20 EXPANSION - Write User File (Level 02 Readers) 
Obsolete Command - Do not use for new designs!! (Use EXPANSION - Diagnostics) 





Write 


Number 


Length 


User 


Expansion 


User 


of User 


of User 


Data 


(17H/67H) 


File 


File 


File 






(02H) 










Yl 


Y2 


Y3 


Y4-Yn 



Yl : WRITE USER FILE 

The VMC request's to write the user file. The length of the file is variable with a 
maximum length of 32 bytes. The contents of the data are defined by the VMC 
manufacturer. If the command is supported but the payment media reader is 
unable to write the payment media (writing problem or data too long) it will 
respond with MALFUNCTION/ERROR. 

Y2 : Number of User File. 

The File identification number. The number and size of data files are defined by 
the payment media reader manufacturer. The maximum number of user files are 
FFh. 

Y3 : Length of user file 
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The length of the user file. The maximum length of the user file is 32 bytes. 
Y4- Yn : Data defined by the VMC manufacturer. 

Reader response: 

No Data response 

7.4.21 EXPANSION - Write Time/Date File (Level 02/03 
readers) 



Expansion 


Write Time/ 


Time 


(17H/67H) 


Date File 


Date 




(03H) 






Yl 


Y2-Y11 



Yl : WRITE TIME/DATE FILE 

The VMC requests to write the Time/Date file. 

Y2- Yll: Time/Date to synchronize the card reader real time clock. The date bytes are 
BCD encoded. 



Y2 = Years (Range: 00..99) 
Y3 = Months (Range: 01.. 12) 
Y4 = Days (Range: 01. .31) 
Y5 = Hours (Range: 00..23) 
Y6 = Minutes (Range: 00..59) 
Y7 = Seconds (Range: 00..59) 

Y8 = Day of Week (Range: 01. .07, Monday = 1.. Sunday = 7) 
Y9 = Week Number (Range: 1 . .53) 
Y10 = Summertime (Range: 00. .01, Summertime = 1) 
Yll = Holiday (Range: 00..01, Holiday = 1) 

If any item of the time/date is not supported use FFH instead. 



7.4.22 EXPANSION - Enable Options (Level 03 readers) 



Expansion 


Optional Feature Bit Enable 


Optional Feature Bits 


(17H/67H) 


(04H) 






Yl 


Y2-Y5 



Level 03 Readers 



Yl : OPTIONAL FEATURE BIT ENABLE 

The VMC can enable which level 3 features it desires. 
Y2 - Y5: Individual expanded feature bits as sent by reader in response to the 17H-00H 

EXPANSION REQUEST ID command. To enable a feature, a bit is set to one. 
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Bits should be sent in descending order, i.e. bit 31 is sent first and bit is sent 
last. All features are disabled after a reset. 

bO - File Transport Layer supported 

bl - = 16 bit monetary format, 1 = 32 bit monetary format 
b2 - multi currency / multi lingual 
b3 - negative vend 
b4 - data entry 

b5 to b31 not used (should be set to 0) 

Note: If 32 bit monetary format (bl) and or multi currency / multi lingual (b2) 
options are enabled, this condition will be known as EXPANDED 
CURRENCY MODE in the rest of the document. 

7.4.23 EXPANSION - FTL REQ TO RCV 



Expansion 


FTL 


REQ TO RCV 


(17H/67H) 


(FAH) 






Yl 


Y2-Y6 



Level 03 Readers (if File Transport Layer option enabled) 

The VMC is requesting to receive data from the reader whose destination address will always be 
10H or 60H. Note that all FTL Commands / Responses are defined in Section 2.6. 



Yl : FTL REQ TO RCV 

The VMC is requesting to receive data from the reader. 

Y2 : FTL Destination Address (Reader = 10H / 60H as defined in Section 2.6. 

Y3 : FTL Source Address 

The source address of the command as defined in Section 2.6. 

Y4 : FTL File ID 

The type of information desired as defined in Section 2.6. 

Y5 : FTL Maximum Length 

The total number of blocks in the file as defined in Section 2.6. 

Y6 : FTL Control 

Data transfer control information as defined in Section 2.6. 



Reader response: 
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Two responses are possible from the reader, either the SEND BLOCK (1DH) which transmits 
the initial (or only) part of the data or the RETRY / DENY (1CH). Note that the response can 
either be immediate or delayed. 



FTL (1DH) 


SEND BLOCK 


SEND BLOCK 


Information 


Zl 


Z2-Z34 



Zl : 1DH response which indicates SEND BLOCK 

Z2 : Destination address of data as defined in Section 2.6 

Z3 : Block # of data as defined in Section 2.6 

Z4-Z34: Data (maximum of 31 bytes) 



or 



FTL (1CH) 


RETRY / DENY 


RETRY / DENY 


Information 


Zl 


Z2-Z4 



Zl : 1CH response which indicates RETRY / DENY 

Z2 : Destination address of response as defined in Section 2.6 

Z3 : Source address of response (10H / 60H) as defined in Section 2.6 

Z4 : Retry delay 



7.4.24 EXPANSION - FTL RETRY / DENY 



Expansion 


FTL 


RETRY / DENY 


(17H) 


(FBH) 






Yl 


Y2-Y4 



Level 03 Readers (if File Transport Layer option enabled) 

The VMC is retrying, denying, or aborting a data transfer to/from the reader whose destination 
address will always be 10H or 60H. Note that all FTL Commands / Responses are defined in 
Section 2.6. 

Yl : FTL RETRY / DENY 
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Y2 



Y3 



Y4 



The VMC is requesting to retry, deny, or abort a data transfer. 

FTL Destination Address (Reader = 10H / 60H) 

The destination address of the command as defined in Section 2.6. 

FTL Source Address 

The source address of the command as defined in Section 2.6. 
FTL Retry Delay 

The time delay required of the sender as defined in Section 2.6. 



Reader response: 

None 



7.4.25 EXPANSION - FTL SEND BLOCK 



Expansion 


FTL 


SEND BLOCK 


(17H/67H) 


(FCH) 






Yl 


Y2-Y34 



Level 03 Readers (if File Transport Layer option enabled) 

The VMC is sending data to the reader whose destination address will always be 10H or 60H. 
Note that all FTL Commands / Responses are defined in Section 2.6. 



Yl : FTL SEND BLOCK 

The VMC is requesting to send data. 

Y2 : FTL Destination Address (Reader = 10H / 60H) 

The destination address of the command / data as defined in Section 2.6. 

Y3 : FTL Block # 

The block # of data as defined in Section 2.6 

Y4- Y34 FTL Data (maximum of 3 1 bytes) 

The actual data block as defined in Section 2.6. 



Reader response: 

None 



7.4.26 EXPANSION - FTL OK TO SEND 



Expansion FTL 



OK TO SEND 
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(17H/67H) 


(FDH) 






Yl 


Y2-Y3 



Level 03 Readers (if File Transport Layer option enabled) 



The VMC is indicating that it is OK for the reader to transfer data. The destination address will 
always be the reader 10H or 60H. Note that all FTL Commands / Responses are defined in 
Section 2.6. 

Yl : FTL OK TO SEND 

The VMC is indicating it is OK to send data. 

Y2 : FTL Destination Address (Reader = 10H / 60H) 

The destination address of the command / data as defined in Section 2.6. 

Y3 : FTL Source Address 

The source address of the command as defined in Section 2.6. 

Reader response: 



One response is possible from the reader which transmits the initial (or only) part of the data. 
Note that the response can either be immediate or delayed. 



FTL (1DH) 


SEND BLOCK 


SEND 


Information 


BLOCK 




Zl 


Z2-Z34 



Zl : 1DH response which indicates SEND BLOCK 

Z2 : Destination address of data as defined in Section 2.6 

Z3 : Block # of data as defined in Section 2.6 

Z4-Z34: Data (maximum of 31 bytes) 



7.4.27 EXPANSION - FTL REQ TO SEND 



Expansion 


FTL 


REQ TO SEND 


(17H/67H) 


(FEH) 






Yl 


Y2-Y6 



Level 03 Readers (if File Transport Layer option enabled) 
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The VMC is requesting to send data to the reader whose destination address will always be 10H 
or 60H. Note that all FTL Commands / Responses are defined in Section 2.6. 

Yl : FTL REQ TO SEND 

The VMC is requesting to send data to the reader. 

Y2 : FTL Destination Address (Reader = 10H / 60H) 

The destination address of the command as defined in Section 2.6. 

Y3 : FTL Source Address 

The source address of the command as defined in Section 2.6. 

Y4 : FTL File ID 

The type of information desired as defined in Section 2.6. 

Y5 : FTL Maximum Length 

The total number of blocks in the file as defined in Section 2.6. 

Y6 : FTL Control 

Data transfer control information as defined in Section 2.6. 



Reader response: 

Two responses are possible from the reader, either the OK TO SEND (1EH) which allows the 
data transfer to start or the RETRY / DENY (1CH). Note that the response can either be 
immediate or delayed. 



FTL (1EH) 


OK TO SEND 


OK TO SEND 


Information 


Zl 


Z2-Z3 



Zl : 1EH response which indicates OK TO SEND 

Z2 : Destination address of response as defined in Section 2.6 

Z3 : Source address of response (10H / 60H) as defined in Section 2.6 

or 
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FTL (1CH) 


RETRY / DENY 


RETRY / DENY 


Information 


Zl 


Z2-Z4 



Zl : 1CH response which indicates RETRY / DENY 

Z2 : Destination address of response as defined in Section 2.6 

Z3 : Source address of response (10H / 60H) as defined in Section 2.6 

Z4 : Retry delay 



7.4.28 EXPANSION - Diagnostics 



Expansion 


Diagnostics 


User 


(17H/67H) 


(FFH) 


Defined 






Data 




Yl 


Y2-Yn 



Yl : DIAGNOSTICS. 

Device manufacturer specific instruction for implementing various 
manufacturing or test modes. 

Y2- Yn : User Defined Data. 

The data portion of this command is defined by the manufacturer and is not part 
of this document. 



Reader response: 



Diagnostics 


User 


Response 


Defined 


(FFH) 




Zl 


Z2-Zn 



Zl : DIAGNOSTICS RESPONSE 

Z2-Zn : User Defined Data. 

The data portion of this response is defined by the manufacturer and is not part of 
this document. 
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7.5 Cashless Device Non-Response Time 

The default maximum non-response time for a cashless device is 5 seconds. This is the 
maximum time for which a cashless device will not respond to a command or a POLL with 
ACK, NAK or a message. The "Application Maximum Response Time" reported in byte Z7 of 
the Reader Configuration Data (7.4.2) supersedes this default value if Z7 is greater. 



7.6 Cashless Device Power Requirements 

The current draw for any cashless device must fall within the following limits. All measurements 
are at the minimum VMC Voltage Output. 

Idle mode = 300 mA. (avg.) continuous 

Transport or Read/Write cycle = 1.5 A @ 50% maximum duty cycle up to 5 seconds. 
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7.7 Example Vend Sessions 



Controller 



EXAMPLE VEND SESSION #1 
(Valid Single Vend) 



Cashless Device 



State 



POLL 
ACK 

VEND REQUEST 

POLL 

ACK 

VEND SUCCESS 



SESSION COMPLETE -> 
POLL -> 



BEGIN SESSION (Session Idle) 

ACK (Vend) 
VEND APPROVED 



ACK 



ACK 



(Session Idle) 



END SESSION 



(Enabled) 
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Controller 




EXAMPLE VEND SESSION #2 
(Valid Multiple Vend) 



Cashless Device 



State 



POLL 
ACK 

VEND REQUEST 

POLL 

ACK 



VEND REQUEST 

POLL 

ACK 

VEND SUCCESS 



VEND SUCCESS -> 



SESSION COMPLETE -> 
POLL -> 



BEGIN SESSION (Session Idle) 

ACK (Vend) 
VEND APPROVED 



ACK 



ACK 



ACK 



(Session Idle) 



ACK (Vend) 
VEND APPROVED 



(Session Idle) 



END SESSION 



(Enabled) 
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EXAMPLE VEND SESSION #3 
(Session cancelled by user with reader return button) 



Controller 



Cashless Device 



State 



POLL -> 

<- BEGIN SESSION (Session Idle) 
ACK -> 

User pushes reader RETURN button 

POLL -> 

<- SESSION CANCEL 
ACK -> 

SESSION COMPLETE -> 

<- ACK 
POLL -> 

<- END SESSION (Enabled) 
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EXAMPLE VEND SESSION #4a 
(Session cancelled by user via coin mechanism 
escrow return button before product was selected) 



Controller 



Cashless Device 



State 



POLL 



ACK 



BEGIN SESSION 



(Session Idle) 



User pushes coin mech. escrow return 



SESSION COMPLETE -> 
POLL -> 



ACK 

END SESSION 



(Enabled) 
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EXAMPLE VEND SESSION #4b 
(Session cancelled by user via coin mechanism 
escrow return button after product was selected) 



Controller 



Cashless Device 



State 



POLL 



ACK 



VEND REQUEST 



<- BEGIN SESSION 



(Session Idle) 



ACK (Vend) 
User pushes coin mech. escrow return 



CANCEL VEND 
POLL 



SESSION COMPLETE -> 
POLL -> 



ACK 

VEND DENIED 
ACK 

END SESSION 



(Session Idle) 



(Enabled) 
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Controller 




EXAMPLE VEND SESSION #5 
(VMC Failure/product not dispensed 
Refund positive) 



Cashless Device 



State 



POLL 



ACK 



VEND REQUEST 



<- BEGIN SESSION 



(Session Idle) 



ACK (Vend) 
Reader deducts purchase price from payment media 



POLL 



VEND APPROVED 



VMC fails to dispense product 



VEND FAILURE 



POLL 



POLL 



SESSION COMPLETE -> 



POLL 



ACK 



Silence during the 
refund operation 



ACK 



ACK 



END SESSION 



(Enabled) 
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Controller 




EXAMPLE VEND SESSION #5A 
(VMC Failure/product not dispensed 
Refund fail) 



Cashless Device 



State 



POLL 



ACK 



BEGIN SESSION 



(Session Idle) 



VEND REQUEST 



POLL 



ACK (Vend) 
Reader deducts purchase price from payment media 



VEND APPROVED 



VMC fails to dispense product 



VEND FAILURE 



ACK 



POLL 



POLL 



SESSION COMPLETE -> 



POLL 



Silence during the 
refund operation 



MALFUNCTION 
ERROR code 
1100yyyy=refund fail 
ACK 



ACK 



END SESSION 



(Level 02 / 03) 
(Level 01) 



(Enabled) 
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EXAMPLE VEND SESSION #6 
(Vend denied by reader) 



Controller 



Cashless Device 



State 



POLL 



ACK 



VEND REQUEST 



<- BEGIN SESSION 



(Session Idle) 



POLL 



ACK (Vend) 
Insufficient funds or payment media/account error 

<- VEND DENIED (Session Idle) 

VMC makes no attempt to dispense product 



SESSION COMPLETE -> 
POLL -> 



ACK 

END SESSION 



(Enabled) 
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Controller 




EXAMPLE VEND SESSION #7 
(Command Out of Sequence Error) 



Cashless Device 



State 



POLL 
ACK 

VEND REQUEST 



EXPANSION 
ID REQUEST 



POLL 



ACK 



BEGIN SESSION (Session Idle) 



ACK 



ACK 



COMMAND OUT 
OF SEQUENCE 



(Vend) 



(Session Idle) 



RESET 



-> {Mandatory} 

<- ACK 



(Inactive) 
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EXAMPLE VEND SESSION #8a 
(Reader busy for longer than max. non response time) 



Controller 




Cashless Device 


State 


POLL 












BEGIN SESSION 


(Session Idle) 


ACK 








VEND REQUEST 












ACK 


(Vend) 


POLL 












[silence...] 


(Reader busy) 


POLLs (numerous) 












[silence...] 


(continued POLLs w/ no response) 


POLL 












ACK 


(restart Non- Response timer) 


POLLs (numerous) 












[silence...] 


(continued POLLs w/ no response) 


POLL 


-> 










[silence...] 


(Reader almost finished) 


POLL 












VEND APPROVED 


(Reader ready) 


ACK 








VEND SUCCESS 


-> 










ACK 


(Session Idle) 


VEND REQUEST 












ACK 


(Vend) 


POLL 












VEND APPROVED 




ACK 








VEND SUCCESS 












ACK 


(Session Idle) 


SESSION COMPLETE 












ACK 




POLL 












END SESSION 


(Enabled) 
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EXAMPLE VEND SESSION #8b 
(Reader busy for shorter than max. non response time) 



Controller 



Cashless Device 



State 



POLL 
ACK 

VEND REQUEST 
POLL 

POLLs (numerous) 

POLL 

POLL 

ACK 

VEND SUCCESS 

VEND REQUEST 

POLL 

ACK 



VEND SUCCESS -> 

SESSION COMPLETE -> 
POLL -> 



BEGIN SESSION 

ACK 
[silence...] 
[silence...] 
[silence...] 

VEND APPROVED 
ACK 



ACK 



ACK 



(Session Idle) 
(Vend) 

(Reader busy) 

(Continued POLLs w/ no response) 
(Reader almost finished) 
(Reader ready) 

(Session Idle) 



ACK (Vend) 
VEND APPROVED 



(Session Idle) 



END SESSION (Enabled) 

NOTE 

If the peripheral omits to respond within the maximum non- response time, it is considered to be 
off-line. 
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Controller 



EXAMPLE VEND SESSION #8c 
(No Response, Reader busy at Vend Request.) 

Cashless Device State/ Comment 



POLL 



ACK 



BEGIN 
SESSION 



VEND REQUEST 



[silence...] 



VEND REQUEST 



VEND REQUEST 



[silence...] 
ACK 



POLL (numerous) 



POLL 



ACK 



VEND 
APPROVED 



Reader busy. The reader may not send the 
response within the t-response(max) timeout 
or hasn't received the command completely 
due to line breakdown 
VMC repeats the command: As the VMC 
isn't sure, that the slave has received the 
command free of errors it repeats it. The 
command itself is not yet performed by the 
reader as long the ACK hasn't been sent. 
Reader busy 

(Vend) 

The reader will now perform the command. 
The response isn't available at the moment, 
thus the VEND REQUEST is only acked 

VMC polls the reader to obtain the data in 
VEND APPROVED 

The reader may send a ACK or [silence] to 
each POLL 

The response to the VEND REQUEST is now 
available. It must be sent within the time 
defined by the APPLICATION MAXIMUM 
RESPONSE TIME. This is measured from 
the ACK following the VEND REQUEST. 



ACK 
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EXAMPLE VEND SESSION #9 
(Pre-approved authorization aborted by coin 
mechanism escrow return button before BEGIN SESSION) 

Controller Cashless Device State 



User swipes payment media 

(Enabled) 

POLL -> 

<- ACK 

READER CANCEL -> 

<- ACK 

(If applicable, reader aborts HOST communications, ejects payment media, 
etc..) 

POLL -> 

<- CANCELLED 
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EXAMPLE VEND SESSION #10 
(Single Negative Vend) 



Controller 



Cashless Device 



State 



POLL 
ACK 



NEGATIVE VEND 
REQUEST 

POLL 



ACK 



BEGIN SESSION 



(Session Idle) 



User inserted a payment media, and inserted then a product, which was 
detected valid, or pressed a selection button to identify the desired product 
which will be inserted later on 



ACK 



(Vend) 



<r VEND APPROVED 

The payment reader is able to add the desired value to the credit 



The product is now fully accepted from the machine or the user has finally 

finished insertion of a valid product 
VEND SUCCESS -> 

<r ACK (Session Idle) 

The payment media reader has added the credit 
SESSION COMPLETE -> 

<- ACK 
POLL -> 

<- END SESSION (Enabled) 

Normally, can or bottle return- vendors may check the product first, before the patron inserts his 
card. It is up to the VMC, to delay the negative vend request, until the session idle state is 
reached. In many return- vendors, from this state, the product is already fully accepted. Therefore, 
there is no need for the further sequences, this means, vend accepted, vend success will follow 
each other immediately. 



If the payment media reader is not able to update the credit, there will be two conditions: 

• The return vendor is able to escrow the product after the vend denied. In this case the session 
complete is sent, the product is return and the credit remains unchanged. 

• The return vendor is not able to escrow the product after vend denied. In this case, session 
complete should be sent and there should be an update credit within the system (VMC), 
which could be returned by other means (i.e. return coins, tokens, etc). 
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If a return vendor is able to escrow the product again, this vendor normally accepts the product 
finally only a vend accepted was sent. In this case there may happen some fault condition which 
allows no final acceptance of the product. The return vendor then closes the session with vend 
failed instead of vend success, indicating to the reader not to update the system credit, or, if the 
payment media is no longer present, request re- insertion of the media. 

EXAMPLE DATA ENTRY SESSION #1 
(Three key Data Entry w/ Prompt & Asterisks for Entries) 



Controller 



Cashless Device 



State 



POLL 



ACK 



Previously Enabled 

DATA ENTRY REQUEST + 
DISPLAY REQUEST (prompt) 



Enabled 



DATA ENTRY 
RESPONSE (Key 1) 

POLL 

ACK 



User pushes Selection Key 1 



ACK 



DISPLAY REQUEST (prompt + *) 



DATA ENTRY 
RESPONSE (Key 2) 

POLL 

ACK 



User pushes Selection Key 2 



ACK 



DISPLAY REQUEST (prompt + **) 



DATA ENTRY 
RESPONSE (Key 3) 

POLL 



ACK 



User pushes Selection Key 3 



ACK 

DISPLAY REQUEST (prompt + *** 
or "Entry OK") 



(Enabled) 



Note: After Display Request Time expires, 
VMC regains control of display 



MDB/ICP Version 3.0 



March 26, 2003 



118 



Multi-Drop Bus / Internal Communication Protocol 
POLL 




ACK 



BEGIN SESSION 



(Session Idle) 
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Controller 



EXAMPLE DATA ENTRY SESSION #2 
(Data Entry with Reader Cancel) 

Cashless Device 



State 



POLL 



ACK 



Previously Enabled 

DATA ENTRY REQUEST + 
DISPLAY REQUEST (prompt) 



Enabled 



DATA ENTRY 
RESPONSE (Key 1) 

POLL 

ACK 



User pushes (valid) Selection Key 



ACK 



DISPLAY REQUEST (prompt + *) 



DATA ENTRY 
RESPONSE (Key 2) 

POLL 

ACK 
POLL 

ACK 



User pushes (invalid) Selection Key 



ACK 



DATA ENTRY CANCEL 



DISPLAY REQUEST ("Error") 



(Enabled) 



After Display Request Time expires, 
VMC regains control of display 



Note that the above scenario is only an example and it may not be prudent to cancel a session 
after the first wrong entry. (Someone could fraudulently obtain a password by trying the 
maximum of selection keys at each position.) 
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EXAMPLE DATA ENTRY SESSION #3 
(Data Entry with VMC Cancel) 



Controller 



Cashless Device 



State 



POLL 



ACK 



DATA ENTRY 
RESPONSE (Key 1) 

POLL 

ACK 



DATA ENTRY 
RESPONSE (FF's) 

POLL 

ACK 



Previously Enabled 

DATA ENTRY REQUEST + 
DISPLAY REQUEST (prompt) 



Enabled 



User pushes Selection Key 



ACK 



DISPLAY REQUEST (prompt + *) 

User walks away & VMC times out 

ACK (Enabled) 
DISPLAY REQUEST ("Try Again") 



After Display Request Time expires, 
VMC regains control of display 
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Section 8 

Communications Gateway 

VMC/Peripheral Communication 
Specifications 

8.1 Introduction 

This section defines the communications bytes sent and received between a 
Communications Gateway (Comms Gateway) and the VMC. The Comms Gateway 
address is 0001 1 xxxB (1 8H). 

Unless otherwise stated, all information is assumed to be in a binary format. 

After the VMC has issued a command, the Comms Gateway must respond with a reply. 
The reply may be an ACK or a detailed message response. If the command format 
expects a response, the Comms Gateway may: 1) respond with an ACK, to 
acknowledge receiving the command, and send the response later as a response to a 
POLL, or 2) immediately respond with the expected message. 

The Comms Gateway response to a command from the VMC may be an ACK, a single 
message, or if there is more data to send it may be a multi message reply, up to the 
MDB maximum of 36 bytes. 

The following command / response set has been defined to provide a means to transfer 
vending information system data from the VMC to the Comms Gateway in one of two 
ways; 

1) Entire DTS files (including DXS, ST, SD1 , G85, SE, and DXE records) are 
transferred using the file transport layer (FTL) of MDB. 

2) Activity "Reports" are sent from the VMC to the Comms Gateway every time 
something happens in the vending system, it is then the Comms Gateways 
responsibility to store and assemble the DTS file. (DXS, ST, SD1 , G85, SE and DXE 
data are not sent.) Obviously, a combination of these two methods can be designed 
to meet specific needs also. 
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8.2 VMC Commands 



VMC Cmd 



Code 



VMC Data 



Comm Gateway response 



RESET 



18H 



00H - Just RESET 



(1) 



SETUP 



19H 



Feature level 
Scale factor 
Decimal places 



(1) 
(1) 
(1) 



01 H - Comms Gateway Config 

Feature level 
Max. App. Resp. 



(2) 



POLL 



1 AH 



00H - Just RESET 



01 H - Comms Gateway Config 

Feature level 
Max. App. Resp. 



(2) 



02H - Request transmit 



03H - Data transmitted 



04H 



Error 

Error code 



05H - DTS Event Acknowledge ( 



) 



06H - Peripheral ID: 


(1) 


Mfg. code 


(3) 


Serial number 


(12) 


Model number 


(12) 


Software ver. 


(2) 


Opt. features 


(4) 



07H - Radio Signal Strength (2) 



1 BH - FTL REQ to RCV (option) (1 ) 



1 CH - FTL RETRY / DENY (option) (1 ) 



1 DH - FTL SEND BLOCK (option) (1 ) 



1 EH - FTL OK to SEND (option) (1 ) 



1 FH - FTL REQ to SEND (option) (1 ) 



FFH - Diagnostics 



(n) 



REPORT 



1 BH 



Type = 01 , Transaction (1 ) 

Transaction Type (1) 

Selection (Row/Col.) (2) 

Price (2) 

Cash in, Coin tubes (2) 

Cash in, Cashbox (2) 

Cash in, Bills (2) 

Value in, Cashless #1 (2) 

Value in, Cashless #2 (2) 

Revalue to Cashless #1 (2) 

Revalue to Cashless #2 (2) 

Cash out (2) 

Discount Amount (2) 

Surcharge Amount (2) 

User Group # (1) 

Price List (1) 

Date (4) 

Time (Z) 
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Type = 02, DTS Event (1) 
DTS Event Code (1 0) 
Date (4) 
Time (2) 
Duration (4) 
Activity (1) 
Terminal ID (12) 


05- DTS Event Acknowledge ( 1 ) 


Type = 03, Asset ID (1) 
Asset Type = On (1) 
Manufacture Code (3) 
Serial Number (12) 
Model Number (12) 
Software Version (2) 

Type = 03, Asset ID (1) 
Asset Type = 8n (1 ) 
Asset Number (20) 




Type = 04, Currency ID (1 ) 
VMu Currency code (d) 

\/MP Pi \rranr\/ \ 
VIVIO L'fcrulllldl r Ullll ^ 1 J 




T\/no — OR Prnrli ir-t in ("W 

Product Identification (20) 
Selection Presence (1) 




CONTROL 


1CH 


00H- Disable (1) 




01 H- Enable (1) 




02H- Transmit (1) 




EXPANSION 


1FH 


uuh - identification 


Ubn - renpnerai id. (i) 
Mfg. code (3) 
Serial number (12) 
Model number (12) 
oonware ver. yd) 
Opt. features (4) 


u i n - reaiure enaDie \ i ) 
Features enabled (4) 




rAM - r 1 L (OpilOn) 

REQ TO RCV 


1 Uri - otlNU Dl_UOr\ 

1CH- RETRY /DENY i 


rbn -ML (Opiionj 
RETRY / DENY 


no uaia | 


rbn - r 1 L (OpilOnj 

SEND BLOCK 

V ) l_ 1 "J La/ 1 > 1 V / \_/ 1 \ 


no uata | 


FDH - FTL (option) 
OK TO SEND 


1DH- SEND BLOCK 


FEH - FTL (option) 
REQ TO SEND 


1 EH -OK TO SEND ' 
1CH- RETRY/DENY 


FFH - Diagnostics (n) 


FFH - Diagnostics (n) 
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8.3 Communications Gateway Command Format 



VMC Command Code/Sub-code VMC Data Comms Gateway Response 

RESET 18H No data Z1 

This command is the vehicle that the VMC should use to tell the Comms Gateway that it 
should perform its initialization procedure. With the exception of the ACK response, it 
should abort all communication and revert to the internally stored operational 
parameters. 

Z1=00 JUST RESET 

Indicates the Comms Gateway has been reset internally or on command 
from the VMC. 

The following initialization sequence is recommended. It should be used after "power 
up", after issuing the RESET command, or after issuing the Bus Reset (pulling the 
transmit line "active" for a minimum of 100 mS). 

POLL-18H 

To obtain "JUST RESET" response 

SETUP -19H 

To obtain Comms Gateway level and configuration information 

EXPANSION IDENTIFICATION - 1 F 00H 

To obtain additional identification information and options 

EXPANSION FEATURE ENABLE - 1 F 01 H 

To enable desired options 

CONTROL / ENABLE - 1 CH / 01 H 

To enable / alert the Comms Gateway to start collecting data and / or 
monitoring for REPORT commands situations. 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 

SETUP 19H Y1 - Y3 Z1 - Z4 

Y1 = VMC feature level 

Indicates the highest Comms Gateway feature level that the VMC 
supports. Currently the highest feature level is 03, with no requirement to 
support previous (obsolete) levels 1 and 2.) 
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Y2 = Scale factor 

The multiplier used to scale all monetary values transferred 
between the VMC and the Comms Gateway. 

Y3 = Decimal places 

The number of decimal places used to communicate 
monetary values between the VMC and the Comms 
Gateway. 

Z1 =01 COMMS GATEWAY CONFIGURATION 

The Comms Gateway is responding to a SETUP command. This response 
includes the following data; 

Z2 = Comms Gateway feature level 

The feature level of the Comms Gateway. Currently the 
highest feature level is 03, with no requirement to support 
previous (obsolete) levels 1 and 2.) 

Z3 - Z4 = Application maximum response time 

The maximum length of time, in seconds, that an Comms 
Gateway may be unable to respond to any commands. This 
includes the time communicating over an external network. 
The VMC should continue POLLing the Comms Gateway 
during this time in an attempt to re-synchronize 
communications earlier. When the Comms Gateway is ready 
to communicate over the bus again, it should respond to the 
next POLL with COMPLETE (if communicating externally) or 
ACK. This time essentially replaces the standard MDB non- 
response time, as such it's default value is equal to the 
defined non-response time (5 seconds). 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 

POLL 1 AH No data Z1 - Zn 

The POLL command is used by the VMC to obtain information from the Comms 
Gateway. This information may include setup information, activity requests, or error 
conditions. An ACK response indicates that no error states exist and either no 
information request is pending or pending information is not yet ready for transmission. 
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In addition to an ACK, the VMC may receive the following POLL responses from the 
Comms Gateway. 
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Z1=00 JUST RESET 

Indicates the Comms Gateway has been reset internally or on command 
from the VMC. 

Z1 =01 COMMS GATEWAY CONFIGURATION 

The Comms Gateway is responding to a SETUP command. This response 
includes the following data; 

Z2 = Comms Gateway feature level 

The feature level of the Comms Gateway. Currently the 
highest feature level is 03, with no requirement to support 
previous (obsolete) levels 1 and 2.) 

Z3 - Z4 = Application maximum response time 

The maximum length of time, in seconds, that an Comms 
Gateway may be unable to respond to any commands. This 
includes the time communicating over an external network. 
The VMC should continue POLLing the Comms Gateway 
during this time in an attempt to re-synchronize 
communications earlier. When the Comms Gateway is ready 
to communicate over the bus again, it should respond to the 
next POLL with COMPLETE (if communicating externally) or 
ACK. This time essentially replaces the standard MDB non- 
response time, as such it's default value is equal to the 
defined non-response time (5 seconds). 

Z1 = 02 REQUEST TO TRANSMIT 

The Comms Gateway is requesting permission to transmit data to an 
external collection device. This is done to control the bus power supply. 
The Comms Gateway should continue sending this response to each 
POLL until permission to transmit has been granted or the need to 
transmit goes away. 

Z1=03 DATA TRANSMITTED 

The Comms Gateway is finished transmitting to an external collect device. 

Z1=04 ERROR 

The Comms Gateway has developed some type of detectable error. The 
error codes will be sent continuously, or until the error is resolved. 

Z2 - Zn = Error code 
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The error codes are ASCII strings taken from the EVA DTS 
Communications fault list. 
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Z1 = 05 DTS EVENT ACKNOWLEDGE 

The Comms Gateway has recognized that a DTS Event has occurred and 
must act accordingly. The specific actions will be defined by the Comms 
Gateway operational specifications. 

Z1=06H PERIPHERAL ID 

Comms Gateway is sending peripheral ID information. This response 
includes the following data; 

Z2 - Z4 = Manufacturer code 

Identification code for the equipment supplier. Sent as ASCII 
characters. Blanks (20H) are acceptable. 

Z5-Z16= Serial number 

Factory assigned serial number sent as numeric ASCII 
characters. All bytes must be sent. Zeros (30H) and blanks 
(20H) are acceptable. 

Z17-Z28= Model number ASCII. 

Manufacturer assigned model number sent as ASCII 
characters. All bytes must be sent. Zeros (30H) and blanks 
(20H) are acceptable. 

Z29 - Z30 = Software version 

Current software version sent as packed BCD. 

Z31 - Z34 = Optional Features 

Each of the 32 bits indicate an optional features availability. 
If the bit is set the feature is available. Currently defined 
options are: 

bO: File transport layer support 

b1: Verbose mode: See REPORT command 

b2 - b31 : Future use, must be set to 0. 



MDB/ICP Version 3.0 



March 26, 2003 



132 



Multi-Drop Bus / Internal Communication Protocol 




Z1 = 07H RADIO SIGNAL STRENGTH 

The Comms Gateway is reporting its signal strength from the network. 
This response includes the following data; 

Z2 = Signal Strength 

The level of radio signal strength detected by the Comms 
Gateway. This is a binary number from 00H to 64H (100%) 
representing the percentage of expected signal. This can be 
sent after every POLL, or as needed due to changes in the 
signal. 

Note that all FTL responses below are defined in Section 2.6. For the Comms 
Gateway, the source address will always be the Comms Gateway (1 8H) as defined in 
Section 2.3. 



Z1 = 1 BH REQ TO RCV (File Transport Layer) 

The Comms Gateway is requesting to receive data from a device or 
VMC. 

Z2 = Destination address of response 

Z3 = Source address of response (1 8H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 

Z1 = 1 CH RETRY/DENY (File Transport Layer) 

The Comms Gateway is requesting a device or VMC to retry or deny the 
last FTL command. 

Z2 = Destination address of response 
Z3 = Source address of response (1 8H) 
Z4 = Retry delay 

Z1 = 1 DH SEND BLOCK (File Transport Layer) 

The Comms Gateway is sending a block of data (maximum of 31 bytes) to 
a device or VMC. 

Z2 = Destination address of data 
Z3 = Block # 

Z4-Z34 = Data (maximum of 31 bytes) 
Z1 = 1 EH OK TO SEND (File Transport Layer) 
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The Comms Gateway is indicating that it is OK for a device or VMC to 
send it data. 

Z2 = Destination address of response 
Z3 = Source address of response (1 8H) 
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Z1 = 1 F REQ TO SEND (File Transport Layer) 

The Comms Gateway is requesting to send data to a device or VMC. 

Z2 = Destination address of response 

Z3 = Source address of response (1 8H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 

Z1 = FFH DIAGNOSTICS 

The Comms Gateway is responding to a EXPANSION/DIAGNOSTICS 
command. This response includes the following data; 

Z2 - Zn User defined data 

Device manufacturer specific responses after receiving 
manufacturing or test instructions. Z1 - Zn implies that any 
number of bytes may be used for the response data from the 
Comms Gateway. 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 

REPORT 1 BH Y1 - Ynn No data 

The REPORT command is used by the VMC to pass activity information to the Comms 
Gateway. If the "Verbose mode" is enabled via the EXPANSION / FEATURE ENABLE 
command, this command must be sent immediately following the completion of any 
activity it is describing. The activities may include; a transaction, a DTS defined event, 
an asset identification, currency identification, or product identification. 

The intent of this command is to provide information so that the Comms Gateway can 
create a Data Transfer Standard file. All of the following fields show their corresponding 
DTS fields for reference, for further detail refer to the Data Transfer Standard. 

If the "Verbose mode" is disabled, only the "DTS Event" report type records must be 
sent. This mode uses the FTL to transfer the complete DTS files and the DTS Event 
report types to alert the VMC of any alarm conditions. 

Since reports data may vary, any field that is not relevant, or not known, should be 
populated with OOH's. All cash values are scaled and decimal adjusted using the data 
provided in the SETUP command. 
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Y1 = Type: The type of activity that is being reported, includes one of the 

following: 



01H 


Transaction 


02H 


DTS Event 


03H 


Asset ID 


04H 


Currency ID 


05H 


Product ID 



If Y1 = 01 H then the following "Transaction" data fields have been identified to be 
included: 



Y2 = Transaction Type 

This field defines the type of transaction that the following data 
describes. The defined transaction types include; 



01 H 


Paid Vend 


02H 


Token Vend 


03H 


Free Vend 


04H 


Test Vend 


05H 


Revalue 


06H 


Negative Vend 


07H 


Vendless* 


08H 


Manual / Service 



* The end of a "Vendless" transaction is defined by the VMC manufacturer, for 
example an escrow request, a failed vend, etc. 

Y3-Y4= Item Number 

This is the binary field used to link REPORT type 01 to REPORT 
type 05. It is an item number, 0000H through FFFFH of the 
selected product involved in the most recent transaction. This 
number is defined by the manufacturer. 

Y5-Y6= Price (PA102) 

The established price of the product involved in the most recent 
transaction. The established price is the price before any 
adjustments i.e. discounts surcharges, etc. 

Y7 - Y8 = Cash in, Coin Tubes (CA303/CA307 or CA1 001 /CA1 002) 
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The value of cash deposited into the coin tubes since the 
completion of the previous transaction. 

Y9 - Y1 = Cash in, Cashbox (CA302/CA306) 

The value of cash deposited into the cashbox since the completion 
of the previous transaction. 

Y1 1 - Y1 2 = Cash in, Bills (CA304/CA308) 

The value of cash deposited into the bill stacker since the 
completion of the previous transactions. 

Y1 3 - Y1 4 = Value in, Cashless Device #1 (DA201 /DA203) 

The value removed from the media in cashless device #1 since the 
completion of the previous transaction. 

Y1 5 - Y1 6 = Value in, Cashless Device #2 (DB201 /DB203) 

The value removed from the media in cashless device #2 since the 
completion of the previous transaction. 

Y1 7 - Y1 8 = Revalue to Cashless Device #1 (DA401 /DA402) 

The value returned to the media in cashless device #1 since the 
completion of the previous transaction. 

Y1 9 - Y20 = Revalue to Cashless Device #2 (DB401 /DB402) 

The value returned to the media in cashless device #2 since the 
completion of the previous transaction. 

Y21 - Y22 = Cash out (CA401 /CA403 or CA402/CA404) 

The total value of the cash dispensed from the system since the 
completion of the previous transaction. 

Y23 - Y24 = Discount Amount (CA701 /CA702) 

The value of any discounts awarded since the completion of the 
previous vend. 

Y25 - Y26 = Surcharge Amount (CA705/CA706) 



MDB/ICP Version 3.0 



March 26, 2003 



137 



Multi-Drop Bus / Internal Communication Protocol 




The value of any surcharges collected since the completion of the 
previous vend. 

Y27 = User Group # (DA701 or DB701 ) 

The user group number that the transaction is associated with. 

Y28= Price List (LA101) 

The price list that the transaction is associated with 

Y29- Y32 = Date (PA501) 

The date of the transaction. This data is sent as BCD in the 
following sequence YYYY/MM/DD. For example, 17 March 2002 
would be 20H 02H 03H 17H. If the date is not known these bytes 
are filled with 99Hs. 

Y33-Y34=Time (PA502) 

The time of the transaction. This data is sent as BCD , 24 hour 
format, in the following sequence HHMM. For example, 6:30 PM 
would be 1 8H 30H. If the time is not known these bytes are filled 
with 99Hs. 

If Y1 = 02H then the following "DTS Event" data fields have been identified to be 
included: 

Y2 - Y1 1 = DTS Event Code (EA1 01 or EA201 or EA701 ) 

This is an alpha-numeric ASCII code defining the event being 
reported. The codes are list in the EVA DTS manual. In addition to 
the standard DTS event codes, an interrogation event is reported 
as "EA3" and a power outage event is reported as "EA7". 

Y12- Y15 = Date (EA102) 

The date of the event. This data is sent as BCD in the following 
sequence YYYY/MM/DD. For example, 17 March 2002 would be 
20H 02H 03H 1 7H. If the date is not known these bytes are filled 
with 99Hs. 

Y16-Y17=Time (EA103) 
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The time of the event. This data is sent as BCD in the following 
sequence HH/MM. For example, 6:30 PM would be 18H 30H. If the 
time is not known these bytes are filled with 99Hs. 



Y18-Y21 = Duration 



(EA206) 



Y22 = 



The duration of the event in total minutes. This data is sent as 
binary. For example, 4 hours and 15 minutes would be 00H 00H 
00H FFH. 

Activity 



(EA205) 



The current status of the events activity. This field is equal to 00H if 
the event is inactive (or not reset for "EA3") or 01 H if the event is 
active (or reset for "EA3"). 

Z1 = 05 DTS EVENT ACKNOWLEDGE 

The Comms Gateway has recognized that a possible alarm situation has 
occurred and must act accordingly. The specific actions will be defined by 
the Comms Gateway operational specifications. 

If Y1 = 03H then the following "Asset ID" data fields have been identified to be included: 

Y2 = Asset Type 

The following code pairs have been defined to represent the type of 
equipment asset that is being communicated. 



Code 


Equipment type 


DTS 
header 

(aa) 


01H/81H 


Audit Module / Data Carrier (DC) Identification 


AM1 


02H/82H 


Bill Validator Identification 


BA1 


03H/83H 


Changer Identification 


CA1 


04H / 84H 


Control Board Identification 


CB1 


05H/85H 


Cashless #1 Identification 


DA1 


06H/86H 


Cashless #2 Identification 


DB1 


07H/87H 


Machine Identification 


ID1 



If Y2 has the MSB = (i.e. Y2 = 01 H) then the following asset data fields 
have been identified to be included: 



Y3 - Y5 = Manufacturer code 



(aa1 01 , first 3 characters) 
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Y6- Y17 = 



Identification code for the equipment supplier. Sent as 
ASCII characters. Blanks (20H) are acceptable. 

Serial number (ococl 01 , 4 th through 1 5 th characters) 



Factory assigned serial number sent as numeric 
ASCII characters. All bytes must be sent. Zeros (30H) 
and blanks (20H) are acceptable. 



Y1 8 - Y29 



Model number 



(cccc102) 



Manufacturer assigned model number sent as ASCII 
characters. All bytes must be sent. Zeros (30H) and 
blanks (20H) are acceptable. 



Y30 - Y31 



Software version (or Build Standard) 



(cccc103) 



Current software version sent as packed BCD. 



If Y2 has the MSB = 1 (i.e. Y2 = 81 H) then the following asset data fields 
have been identified to be included: 



If Y1 = 04H then the following "Currency ID" data fields have been identified to be 
included: 



The packed BCD Country / Currency code of the VMC can be sent 
in two different forms depending on the value of the left most BCD 
digit. 

If the left most digit is a 0, the International Telephone Code is used 
to indicate the country that the changer is set-up for. For example, 
the USA code is 00 01 H (Z2 = 00 and Z3 = 01 ). 

If the left most digit is a 1 , the latest version of the ISO 421 7 
numeric currency code is used. For example, the code for the US 
dollar is 1 8 40H (Z2 = 1 8 and Z3 = 40) and for the Euro is 1 978 (Z2 
= 19 and Z3 = 78). 



Y2-Y21 = Asset Number 



(aoc105 oraa106) 



The asset number of the equipment. This is a 
reference number used for tracking purposes, 
separate from the serial number. It is usually 
programmed by the equipment operator. 



Y2 - Y3 = VMC's Country / Currency Code 



(ID402) 
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All new designs after July, 2000 must use the ISO 421 7 numeric 
currency codes. 

Y4 = VMC's Coin Scaling Factor / Currency Description (ID403) 

The multiplier used to scale all monetary values transferred 
between the VMC and the vending machines monetary system. 

Y5= VMC's Decimal Point (ID401) 

The number of digits to the right of the decimal point. This field is 
used in countries whose currency requires a number of digits to the 
right of the decimal point other than 2. 

If Y1 = 05H then the following "Product ID" data fields have been identified to be 
included: 

Y2-Y3= Item Number 

This is the binary field used to link REPORT type 01 to REPORT 
type 05. This number is defined by the manufacturer. 

Y4-Y9= Product Number (PA101) 

This is the ASCII representation of the Item Number that should be 
included in the DTS file. All bytes must be sent, leading blanks 
(20H) are acceptable. 

Y1 - Y29 = Product Identification (PA1 03) 

The ASCII product identification that should identify the product 
itself, as in a name (chips/crisps) or an ID number / bar code. All 
bytes must be sent, leading blanks (20H) are acceptable. 

Y30= Selection Presence Status (PA107) 

This field is set to 00H if a vend mechanism (motor, solenoid, etc.) 
is present for this selection. This field is set to 01 H if a vend 
mechanism is not present. 

An example of a 01 H being sent would be if the vend mechanism 
was present previously, and something occurred so that it is not 
being currently detected (i.e., removed, broken wire, etc.). It is not 
intended to indicate that a product is not available for vending (i.e., 
sold out). 
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VMC Command Code/Sub-code VMC Data Comms Gateway Response 

CONTROL 1CH Y1 No data 

This command is the vehicle that the VMC uses to control the Comms Gateway's use of 
an external collection device. For example when it should, or should not, transmit 
through the external collection device. The information is identified by one of the 
following subcommands; 



Y1 = 00 Disabled 



No external transmissions will be granted and no REPORT commands will 
be sent. 



Y1 = 01 Enabled 



External transmissions may be requested and REPORT commands will be 
sent. 



Y1 = 02 Transmit 



Permission to transmit and / or receive data is granted, or a transmission 
session is requested. A DATA TRANSMITTED response to a POLL must 
be sent when the transmission session is complete. 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 

EXPANSION/ 1FH/00H Y1 Z1 - Z34 

IDENTIFICATION 

Y1=00H IDENTIFICATION subcommand 

The VMC is requesting Comms Gateway identification information for asset tracking 
and optional feature purposes. 

Z1=06H PERIPHERAL ID 

Comms Gateway is sending peripheral ID information. This response 
includes the following data; 

Z2 - Z4 = Manufacturer code 

Identification code for the equipment supplier. Sent as ASCII 
characters. Blanks (20H) are acceptable. 
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Z5 - Z1 6 = Serial number 



Factory assigned serial number sent as numeric ASCII 
characters. All bytes must be sent. Zeros (30H) and blanks 
(20H) are acceptable. 

Z17-Z28= Model number ASCII. 

Manufacturer assigned model number sent as ASCII 
characters. All bytes must be sent. Zeros (30H) and blanks 
(20H) are acceptable. 

Z29 - Z30 = Software version 

Current software version sent as packed BCD. 

Z31 - Z34 = Optional Features 

Each of the 32 bits indicate an optional features availability. 
If the bit is set the feature is available. Currently defined 
options include: 

bO: File transport layer support. 

b1 : Verbose mode: See REPORT command 

b2 - b31 : Future use, must be set to 0. 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 

EXPANSION/ 1FH/01H Y1 - Y5 No data 

FEATURE ENABLE 

Y1 = 01 H FEATURE ENABLE subcommand 

This command is used to enable each of the optional features defined in Z32-Z35 of the 
PERIPHERAL ID response. The VMC should send the EXPANSION /IDENTIFICATION 
command, receive the PERIPHERAL ID response, perform a logical OR with the 
optional features it wants to enable, and return the resulting enabled features back to 
the Comms Gateway by setting a bit to 1 for each respective optional feature enabled. 
All optional features are disabled after reset. 

Y2 - Y5 = Optional features enabled 

Each of the 32 bits indicates an optional features state. If the bit is set the feature 
is enabled. 
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VMC Command Code/Sub-code VMC Data Comms Gateway Response 



EXPANSION OFH FAH Y1-Y5 Z1 - Zn (immediate or POLLed) 

COMMAND FTL REQ TO RCV 



The VMC is requesting to receive data from the Comms Gateway whose destination 
address will always be (1 8H). Note that all FTL Commands / Responses are defined in 
Section 2.6. 



Y1 = Destination address of command (18H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 

or 

Z1 = 1 CH which indicates RETRY / DENY 

Z2 = Destination address of response 

Z3 = Source address of response (1 8H) 

Z4 = Retry delay 
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VMC Command Code/Sub-code VMC Data Comms Gateway Response 

EXPANSION OFH FBH Y1-Y3 None 

COMMAND FTL RETRY / DENY 

The VMC is retrying, denying, or aborting a data transfer to/from the Comms Gateway 
whose destination address will always be (1 8H). Note that all FTL Commands / 
Responses are defined in Section 2.6. 



Y1 = Destination address of command (18H) 

Y2 = Source address of command 

Y3 = Retry delay 



VMC Command Code/Sub-code VMC Data Comms Gateway Response 

EXPANSION OFH FCH Y1-Y33 None 

COMMAND FTL SEND BLOCK 

The VMC is sending data to the Comms Gateway whose destination address will 
always be (1 8H). Note that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command & data (1 8H) 

Y2 = Block # 

Y3 - Y33 = Data (maximum of 31 bytes) 



VMC Command Code/Sub-code VMC Data Comms Gateway Response 

EXPANSION OFH FDH Y1-Y2 Z1 -Z34 (immediate or POLLed) 

COMMAND FTL OK TO SEND 

The VMC is indicating that it is OK for the Comms Gateway to transfer data. The 
destination address will always be the Comms Gateway (1 8H). Note that all FTL 
Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (18H) 

Y2 = Source address of command 

Z1 = 1DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Source address of data 

Z4 - Z34 = Data (maximum of 31 bytes) 
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VMC Command Code/Sub-code VMC Data Comms Gateway Response 



EXPANSION OFH FEH Y1-Y5 Z1 - Zn (immediate or POLLed) 

COMMAND FTL REQ TO SEND 



The VMC is requesting to send data to the Comms Gateway whose destination address 
will always be (1 8H). Note that all FTL Commands / Responses are defined in Section 
2.6. 



Y1 = Destination address of command (18H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1 EH which indicates OK TO SEND 

Z2 = Destination address of response 

Z3 = Source address of response (1 8H) 

or 

Z1 = 1CH which indicates RETRY /DENY 

Z2 = Destination address of response 

Z3 = Source address of response (1 8H) 

Z4 = Retry delay 

VMC Command Code/Sub-code VMC Data Comms Gateway Response 



EXPANSION/ 1FH/FFH Y1 - Yn Z1 - Zn 

DIAGNOSTICS 



Y1 = FFH DIAGNOSTICS subcommand 

Device manufacturer specific instruction for implementing various 
manufacturing or test modes. 

Y2 - Yn = User defined data 

The data portion of this command is defined by the manufacturer and is 
not part of this document. 

Z1 = FFH DIAGNOSTICS 

The Comms Gateway is responding to a EXPANSION/DIAGNOSTICS 
command. This response includes the following data; 

Z2 - Zn = User defined data 
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Device manufacturer specific responses after receiving 
manufacturing or test instructions. Z1 - Zn implies that any 
number of bytes may be used for the response data from the 
Comms Gateway. 

8.4 Communications Gateway Non-Response Time 

The maximum non-response time for a Comms Gateway is 5 seconds. This is the 
maximum time for which a Comms Gateway will not respond to a command with ACK, 
NAK, or a data message. 

8.5 Communications Gateway Power Requirements 

The current draw for any Comms Gateway must fall within the following limits. All 
measurements are at the minimum VMC Voltage Output. 

Idle mode = 300 mA. (avg.) continuous 

Active mode = 1 .8 A continuous and up to 2.5 A (max) for an accumulated 

maximum of 10 seconds. The active power mode must be initiated 
by the REQUEST TO TRANSMIT followed by the 
CONTROL/TRANSMIT. The active power mode must be closed by 
sending the DATA TRANSMITTED. During this time the VMC will 
make its own decisions about which other peripherals will be 
disabled or not. This may result in the entire machine being 
disabled for normal vending. 
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8.6 Communications Gateway Examples 



Fvpnt 

LVCIIl 


Fyrhannp 


rower on nesei ai vivio or juo i ficoc i receiveu uy viviv^ 
anv nthpr timp 


riesei sequence 
Fnahlp ^pnupnpp 

i — i iaui& o u v_* i i \_/ \j i 


Communications Gateway is triggered to send a file 


Request sequence 
Transmit sequence 


VMC is triggered to send a file 


Dump sequence 
Transmit sequence 


DTS Event situation occurs at VMC 


DTS Event sequence 
Request sequence 
Transmit sequence 


Error situation is detected at Comms Gateway 


Error sequence 


Every vend completion 


Vend sequence 



Reset sequence 



Comms Gateway 




RESET (18) 






Reset command 






ACK 




POLL (1 A) 






Must be sent once 






JUST RESET (00) 


reset, internal or 


ACK 






external 


SETUP (19...) 






Establish operation 






CONFIG. (01...) 


configuration 


ACK 








EXPANSION/ID 






Send asset information 


(1F/00...) 












PERIPHERAL ID (06...) 


Get asset information 


ACK 






EXPANSION/FEATURE 






Enable additional feature if 


ENABLE (1F/01 ...) 






necessary 






ACK 




Enable sequence 














Comments 


CONTROL/ENABLE 






Enable command 


(1C01) 












ACK 




Disable sequence 












Comms Gateway 


Comments 


CONTROL/DISABLE 






Disable command 


(1C00) 












ACK 
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Request sequence 






File transfer done 


using the MDB 


file transport layer 


Dump sequence 
VMC 


Comms Gateway 





File transfer done using the MDB file transport layer 



VMC 

POLL (1 A) 

ACK 



*" Request to transmit (02) 



CONTROL/ TRANSMIT 
(1C/02) 



«■ ACK 



POLL (1 A) 



ACK 



Continue POLLing until 



POLL (1 A) 
ACK 

DTS Event sequence 
VMC 

REPORT (1B/ 02...) 



*■ Data transmitted (03) 




ACK 



Repeat until recognized 



REPORT (1B/02...) 



Error sequence 
VMC 

POLL (1 A) 
ACK 

Activity sequence 



«■ DTS EVENT 

ACKNOWLEDGE (05) 



' 



«■ ERROR (06) 




Sent continuously, or until 
the error is resolved 





REPORT (1B...) 



Sent every activity 



ACK 
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Section 9 

Universal Satellite Device (USD) 
VMC/Peripheral Communication Specifications 

9.1 Introduction 



An MDB Universal Satellite Device (USD) is a vending device which lacks 

customary credit acceptance peripherals. As such, a USD must rely on a 
host vending machine controller (VMC) to establish credit sufficient to 
perform a vend. The specification herein describes a protocol by which a 
USD and a VMC exchange messages and credit via the MDB bus. 

9.1.1 Definitions 

This section defines the non-response and application response time, base addresses, and the communication bytes sent by the MDB 
Universal Satellite Device (USD) and a Vending Machine Controller. 

• The default maximum non-response time of the USD is 5 seconds. 

• The default maximum appication response time of the USD is 5 seconds. 

• Three consecutive USD base addresses are defined to allow multiple USDs 
to operate simultaneously from a single VMC 

• As defined in Section 2.3, the USD Base addresses are as follows: 
01000xxxB (40H), 01001xxxB (48H), and 01010xxxB (50H). 

• The specification defined herein assumes a USD base address of 40H in all 
examples. It should be understood that differing USD base addresses (48H 
and 50H) will follow the same command format. 

• Multi-message responses to a single command are supported. Message 
length is subject to the 36 byte limit imposed by the MDB standard. 

• Unless stated otherwise, all byte information contained herein is assumed to 
be in a binary format. 

• Y n represents bytes transmitted by the VMC, and Z n are bytes transmitted by 
the USD. 

• When words are referenced, they consist of two bytes with the higher order 
byte first. 

High Low 



word= b15 ... b8 b7 ... bO 



9.2 USD Summary 



This section is a summary of the USD command set and an overview of the modes of operation. 

9.2.1 Command Summary 
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Kbob 1 


4(J 


Command for USD to self-reset. 


SETUP 


41 


Command to configure USD to VMC requirements. 


POLL 


42 


Command to request for USD activity status. 


VEND 


43 


Command for vend approve / deny. 


FUNDS 


44 


Command to send funds available or to set prices. 


CONTROL 


45 


Command to enable/disable USD. 


EXPANSION 


47 


Command to allow addition of features and 
enhancements. 



9.2.2 Overview 

The USD Command set described herein allows USDs' to be controlled under 
the following three modes of operation. The USD's mode of operation is 
determined by the USD's configuration byte 1 and the sequence of commands the 
VMC uses. 



Mode One 



Mode Two 



Mode Three 



VMC is used to select items to be vended from the USD and the 
VMC contains all pricing information. The USD receives vend 
requests from the VMC and reports vend success or failure. 

The USD or the VMC may select items to be vended. The USD 
may have special requirements for price and/or selection ID 
display. In this case, the USD may issue a FUNDS request to 
retrieve this information. The USD must then issue a VEND 
request to gain approval from the VMC before a vend can take 
place. 

The USD selects items to be vended and has its own pricing 
information. The USD must issue an vend request to the VMC 
and gain approval before a vend can take place. 



9.3 Command Protocol 

This section contains the complete command set relating to the USD. 



9.3.1 RESET 



1 Configuration byte refers to byte Z31 of the sequence Z31 through Z34 of the expansion 07 command. 
Please refer to page 9.12 for more information on how this byte influences the USD's mode of operation. 
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RESET 


40 


No data bytes. 


ACK 



The RESET command is the vehicle that the VMC should use to instruct the USD 
to return to its default (power on) operating mode. The USD should respond to a 
reset command with an ACK to acknowledge receipt of the reset command. The 
USD must not accept any vend requests until the VMC issued setup command 
sequence has been completed. 

The USD must also respond to the VMC issued "master reset" which resets all 
MDB peripheral devices. The VMC causes a master reset by transmitting a 
continuous break condition for a minimum of 1 00 milliseconds. 

To ensure proper initialization, the USD should issue a "just reset" (see POLL 
response 00) whenever it's pricing or configuration has changed. 



9.3.2 SETUP 



Command 


Code 


VMC Data 


USD Response Data 


SETUP 


41 


5 bytes: Y1 -Y5 


7 bytes: 04 + Z1 - Z6 



The SETUP command is the vehicle that the VMC should use to configure the 
USD for feature level, credit scaling factor, display decimal place, and maximum 
vend approve/deny time. The USD responds to this command by returning it's 
feature level, highest vend price (divided by the scaling factor), selection 
configuration, and maximum application response time. 

Alternatively, if the USD is not prepared to render a full response to the SETUP 
command, it may reply with an ACK. If this occurs, the USD must transmit it's 
setup data later, in response to a POLL command (see POLL command, 
response 04). Until the SETUP command has been received by the USD, and 
the USD has correspondingly returned it's own setup data to the VMC, all vend 
requests will be disallowed. 



Data sequence transmitted by the VMC to the USD during SETUP 



VMC Data 


Meaning or interpretation 


Y1 = 


VMC Feature level, Indicates current feature level of the VMC. 
Currently defined level is one. 2 


Y2 - Y3 = 


Scaling factor 2 bytes (word). All transactions with the USD 
must be evenly divisible by this number. 


Y4 = 


Decimal place (02=US). Indicates the position of the decimal 



2 Feature level of the VMC is sent to allow the USD to arbitrate command compatibility with the VMC. 
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place on the USD's optional credit display 


Y5 = 


VMC maximum approve / deny time in seconds, FF = 255 
seconds. 


Data sequence transmitted by the USD to the VMC during SETUP 


USD 


Meaning or interpretation 


04 + Z1 = 


USD Feature level, indicates current feature level of the USD. 
Currently defined level is one. 3 


Z2 - Z3 = 


Maximum price on USD in 2 bytes (word). Indicates the 
highest priced item on the USD. 4 USD should return FF FFh if 
it does not have internal pricing capability. 


Z4 - Z5 = 


Item number, defined by the manufacturer configuration 
(Binary). 


Z6 = 


USD maximum application response time in seconds, FF = 255 
seconds. 



3 Feature level of the USD is sent to allow the VMC to arbitrate command compatibility with the USD. The 
USD may opt to send this data later in response to a POLL. 

4 The maximum price on the USD is returned to the VMC so this price can be used in the computation of 
maximum credit acceptance. 
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Command 


Code 


USD response Data 


USD Response Description 


POLL 


42 


00 


USD has just been reset, or 
wishes to be reset by the VMC. 






01+4 bytes Z1 - Z4 


Vend request, USD requests 
approval to vend a specified item 
from VMC. 






02 


Vend or home success, requested 

Vol IU Ul I IUI I lo Vvdo oUUUcoolUI. 






03 + 4 bvtes Z1 - Z4 


\/onH hnmo foil rom loctoH \/onH 
VoMU Ul IIUIIIU Iclll, IcLjUcbLcU VfcMIU 

or home has failed. Reason for 
failure is returned. 






04 + 6 bytes Z1 - Z6 


USD configuration and setup data. 






05 + 2 bytes Z1 - Z2 


USD item price request. 






06 + 2 bytes Z1 - Z2 


USD Error codes. 






07 + 34 bvtes Z1 - 
Z34 


USD Peripheral ID strina 






08 + 4 bytes Z1 - Z4 


USD Status response. 






09 + n bytes Z1 - Zn 


USD multiple data block transfer 
response. 






OA + n bytes Z1 - Zn 


USD single data block response 






1 B + 5 bytes Z2 - Z6 


FTL REQ TO RCV response 






1C + 3bytes Z2-Z4 


FTL RETRY / DENY response 






1 D + n bytes Z2 - Zn 


FTL SEND BLOCK response 






1 E + 2 bytes Z2 - Z3 


FTL OK TO SEND response 






1 F + 5 bytes Z2 - Z6 


FTL REQ TO SEND response 






FF + Z1 - Zn 


USD Diagnostic response. 



The POLL command is used by the VMC to obtain status information from the 
USD. The same command is used by the USD to indicate a reset, request a 
vend, indicate vend success, indicate the reason for a vend failure, request the 
price of an item, send configuration and/or error data, return the USD's peripheral 
identification string, control the transmission and reception of data blocks, return 
a status and/or diagnostic response. 

The USD responds to the POLL command with either an ACK, or a multi-byte 
response if there is more information to convey. 
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Data sequence transmitted by the USD to the VMC after a Reset Request 



USD 

Response 


Meaning or interpretation 


00 


The 00 response indicates that the USD has just been reset or 
wishes to be reset 5 . 


Data sequence transmitted by the USD to the VMC for a Vend Request 


USD 


Meaning or interpretation 






01 + Z1 - Z2 = 


Selection in 2 bytes. Indicates the product to be vended by 
item number, defined by the manufacturer, as part of a vend 
request. 


Z3 - Z4 = 


Scaled product price in 2 bytes (word). Indicates the price of 
the product to be vended divided by the scaling factor. A price 
of FFFF is transmitted if the USD does not contain price 
information. 


Data sequence transmitted by the USD to the VMC after a Vend or Home 
success 


USD 


Meaning or interpretation 


02 


Indicates that the requested vend or home was successful. 


Data sequence transmitted by the USD to the VMC after a Vend or Home 
Fail 


USD 

Response 


Meaning or interpretation 


03 + Z1 - Z2 = 


USD item number, defined by the manufacturer. 


Z3 - Z4 = 


Bits: bO = Selection sold out. 

b1 = Selection motor / actuator jam. 
b2 = Non-existent motor / actuator. 
b3 = Invalid selection range 6 . 
b4 = Health safety error. 
b5- b15 = Not defined. 



5 The VMC is expected to reconcile whether the USD is transmitting a 00 in confirmation of a 
VMC issued reset that has just occurred, or as an unsolicited request to be reset. The context of 
the VMC's prior communication activity should be used in making this assessment. 
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Data sequence transmitted by the USD to the VMC if SETUP response 
delayed 




04 + Z1 = 


USD Feature level, Indicates current feature level of the USD. 
The currently defined level is one. 7 


Z2 - Z3 = 


Maximum price on USD 2 bytes (word). Indicates the highest 
priced item on the USD. 8 USD should return FF FFh if it does 
not have internal pricing capability. 


Z4 - Z5 = 


Item number, defined by the manufacturer. 


Z6 = 


USD maximum application response time in seconds, FF = 
255 seconds. 


Data sequence transmitted by the USD if the USD needs pricing 
information 




Meaning or interpretation 


05 + Z1 - Z2 = 


Item number, defined by the manufacturer. 


Data sequence transmitted by the USD if the USD has a failure to report to 
VMC 


USD 

Response 


Meaning or Interpretation 1 


06 + Z1 - Z2 = 


Bits: bO = Health Safety violation. 

b1 = Home or Chute sensor failure 
b2 = Keypad or Selection switch failure 
b3-b15 = Not defined. 



Data sequence transmitted by the USD for peripheral ID 



This error code is included to identify actuators that may not be present within the initially 
defined row and column configuration. See bytes Z4 and Z5 of the USD's setup response. This 
is typical in a snack machine implementation where some trays may not be populated with a full 
complement of motors and/or actuators. 

7 Feature level of the USD is sent to allow the VMC to arbitrate command compatibility with the 
USD. The USD may have elected to transmit this setup data in fulfillment of an earlier SETUP 
command. 

8 The maximum price on the USD is returned to the VMC so this price can be used in the 
computation of maximum credit acceptance. 
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Meaning or Interpretation 


07 + Z1 - Z4 = 
Z5- Z16 = 
Z1 7 - Z28 = 
Z29 - Z30 = 
Z31 - Z34 = 


Manufacturer ID Code. 


USD Serial Number. 


USD Model Number. 


USD Software Version. 


Optional feature bits. 


Data sequence transmitted by the USD to the VMC after a Status request 


USD 

Response 


Meaning or interpretation 


08 + Z1 - Z2 = 


Item number, defined by the manufacturer. 


Z3 - Z4 = 


Bits: bO = Selection sold out. 

b1 = Selection motor / actuator jam. 
b2 = Non-existent motor / actuator. 
b3 = Invalid selection range. 
b4 = Health safety error. 
b5- b15 = Not defined. 



Data sequence transmitted by the USD to the VMC after a USD data transfer 
command 



USD 

Response 


Meaning or interpretation 


09 + Z1 = 


Z1 = 00 USD requests to receive data block Z2 from VMC 
Z1 = 01 USD requests to send Z2 data block(s) to VMC 
Z1 = 02 USD data block response where: 

Z2 = data block number 

Z3 - Zn = contents of data block 


Z2 = 


Z2 = Block number USD requests to receive if Z1 = 00 
Z2 = Number of blocks the USD requests to send if Z1 = 01 
Z2 = Block number the USD is sending if Z1 = 02. 


Z3 - Zn = 


Contents of data block sent by USD to VMC if Z1 = 02 
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Data sequence transmitted by the USD to the VMC to send a single block of 
data 



USD 


Meaning or interpretation 


OA + Z1 - Zn= 


Z1 -Zn = Arbitrary data to be received by the VMC. The 
number "n" must be less than 35 per MDB standards 


Data sequence transmitted by the USD to the VMC after an File Transport 
Layer (FTL) REQ TO RCV command 


USD 


Meaning or interpretation 


Z1=1B + 
Z2- Z6 


The USD is requesting to receive data from a device or VMC 

Z2 = Destination address of response 

Z3 = Source address of response (40H, 48H, 50H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 


Data sequence transmitted by the USD to the VMC after an File Transport 
Layer (FTL) RETRY / DENY command 


USD 

Response 


Meaning or interpretation 


Z1=1C + 
Z2- Z4 


The USD is requesting a device or VMC to retry or deny the 

last FTL command. 

Z2 = Destination address of response 

Z3 = Source address of response (40H, 48H, 50H) 

Z4 = Retry delay 


Data sequence transmitted by the USD to the VMC after an File Transport 
Layer (FTL) SEND BLOCK command 


USD 

Response 


Meaning or interpretation 


Z1=1D + 
Z2 - Z34 


The USD is sending a block of data (maximum of 31 bytes) 

to a device or VMC. 

Z2 = Destination address of response 

Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 
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Data sequence transmitted by the USD to the VMC after an File Transport 
Layer (FTL) OK TO SEND command 



USD 

Response 


Meaning or interpretation 


Z1=1E + 
Z2- Z3 


The USD is indicating that it is OK for the device or VMC to 
send it data. 

Z2 = Destination address of response 

Z3 = Source address of response (40H, 48H, 50H) 



Data sequence transmitted by the USD to the VMC after an File Transport 
Layer (FTL) REQ TO SEND command 



USD 

Response 


Meaning or interpretation 


Z1=1F + 
Z2- Z6 


The USD is requesting to send data to a device or VMC. 

Z2 = Destination address of response 

Z3 = Source address of response (40H, 48H, 50H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



Data sequence transmitted by the USD to the VMC after a diagnostic 
command 



USD 

Response 


Meaning or interpretation 


FF + Z1 - Zn 


Diagnostic response. 



9.3.4 VEND 



Command 


Code 


Sub- 


VMC Data 


Response Data 






Cmd 




VEND 


43 


00 


none 


none 




43 


01 


none 


none 




43 


02 


2 bytes Y1 -Y2 


none 




43 


03 


2 bytes Y1 -Y2 


none 




43 


04 


2 bytes Y1 -Y2 


5 bytes: 08 + Z1 - Z4 
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The VEND command is the vehicle that the VMC uses to signal vend approval or 
disapproval in response to a USD issued vend request (POLL response 01). The VEND 
command can also be used by the VMC to initiate a vend, home a selection, or query 
the status of a selection on the USD. 



00~= 


Requested vend approved. 


01 = 


Requested vend disapproved. 


02 = 


Vend specified Item number, defined by the manufacturer. 


03 = 


Home specified Item number, defined by the manufacturer. 


04 = 


Request status of specified Item number, defined by the 
manufacturer. 



Data sequence transmitted by the USD to the VMC after a Status request 



USD 

Response 


Meaning or interpretation 


08 + Z1 - Z2 = 


Item number, defined by the manufacturer. 


Z3 - Z4 = 


Bits: bO = Selection sold out. 

b1 = Selection motor / actuator jam. 
b2 = Non-existent motor / actuator. 
b3 = Invalid selection range. 
b4 = Health safety error. 
b5- b15 = Not defined. 



9.3.5 FUNDS 



Command 


Code 


Sub- 
Cmd 


VMC Data 


Response Data 


FUNDS 


44 


00 


2 bytes: Y1 -Y2 


none 




44 


01 


6 bytes: Y1 -Y6 


none 



The FUNDS command is the vehicle the VMC should use to specify the funds 
available for vending. The FUNDS 00 command is issued by the VMC whenever 
the level of credit changes. Typically, the USD would display the credit 
information returned by a FUNDS 00 command on a credit display. The FUNDS 
01 is issued by the VMC in response to an item price request (POLL response 
05) by the USD. 



Sub-Cmd 
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00 + Y1 - Y2 = 



Funds available in 2 bytes (word), scaled by the coin scaling 
factor. 



Sub Cmd 


Meaning or interpretation 


01 + Y1 - Y2 = 


Item number, defined by the manufacturer. 


Y3 - Y4 = 


Selection price in 2 bytes (word) scaled by coin scaling factor. 


Y5 - Y6 = 


Alphanumeric selection identifier 2 bytes (word), or FFFF if not 
available. 9 



9.3.6 CONTROL 



Command 


Code 


Sub- 
Cmd 


VMC Data 


Response Data 


CONTROL 


45 


00 


none 


none 




45 


01 


none 


none 



This command is the vehicle the VMC should use to enable or disable the USD. 



Sub-Cmd 


Meaning or interpretation 


00 


Disable USD. 


01 


Enable USD. 



EXPANSION 



Command 


Code 


Sub- 
Cmd 


VMC Data 


Response Data 


EXPANSION 


47 


00 


None 


07 + Z1 - Z34 Peripheral 
ID string and feature bits. 




47 


01 


Y1 - Y4 


none 




47 


02 


Y1 


none 




47 


03 


Y1 - Yn 


none 




47 


04 


Y1 


09 + Z1 + Z2 - Zn 




47 


05 


Y1 - Yn 


none 




47 


FA 


Y1 - Y5 


1D + Z2-Z34 or 
1C + Z2-Z4 




47 


FB 


Y1 - Y3 


none 



9 Alpha-numeric selection identifier is provided to the USD for display purposes only. 
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47 


FC 


Y1 - Y33 


none 




47 


FD 


Y1 - Y2 


1D + Z2-Z34 




47 


FE 


Y1 - Y5 


1E + Z2-Z3 or 
1C + Z2- Z4 




47 


FF 


Diagnostics 


Diagnostic response. 



Data sequence transmitted by the USD to the VMC after an expansion 00 
sub-command 





07 + Z1 - Z3 = 


Manufacturer ID Code. 


Z4- Z15 = 


USD Serial Number. 


Z1 6 - Z27 = 


USD Model Number. 


Z28 - Z30 = 


USD Software Version. 


Z31 - Z34 = 


Optional feature bits: 

bO = USD is capable of storing and controlling pricing. 

b1 = USD is capable of selecting items to vend. 

b2 = USD is capable of supporting the File Transport 

Layer. This support is defined in Section 2.6. 
b3 - b31 = Available for future use. 



Sub-Command used by the VMC to enable optional feature bits on the USD 







01 + Y1 - Y4 


Enable optional feature bits defined in Z31-Z34 above. 
Feature is enabled if bit is set to 1 , all features are disabled 
after a reset. 



Sub-Command used by the VMC to identify the number of data blocks it 
wishes to send to the USD 



Sub-Cmd 


Meaning or interpretation 


02 + Y1 


Number of data blocks the VMC has to send to the USD 
(Binary) 



Sub-Command used by the VMC to transmit a data block to the USD (Y2- 
Yfi) and to identify the current block number being transmitted (Y1) 



Sub-Cmd 


Meaning or interpretation 


03 + Y1 


Block number the VMC is transmitting to the USD 



MDB/ICP Version 3.0 



March 26, 2003 



162 



Multi-Drop Bus / Internal Communication Protocol 




Y2- Yn 10 


Data the VMC is transmitting to the USD 


Sub-Command used by the VMC to request that the USD send or re-send 
data block number (Y1) 


Sub-Cmd 




04 + Y1 


VMC requests USD to send block Y1 


Sub-Command used by the VMC to send a single block of data to the USD 


Sub-Cmd 


Meaning or interpretation 


05 + Y1 - Yn 


VMC sends a single block of data consisting of Y1 ..Yn 


Sub-Command used by the VMC for an FTL REQ TO RCV. The Z1 - Zn 
response can be either immediate or delayed (POLLed). 


Sub-Cmd 


Meaning or interpretation 


FA + Y1 - Y5 

USD Response 

Z1 - Z34 

or 


The VMC is requesting to receive data from the USD whose destination address will always be 
(40H, 48H, 50H). Note that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (40H,48H,50H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Meaning or interpretation 

Z1 = 1 DH which indicates SEND BLOCK 
Z2 = Destination address of data 
Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 
or 

Z1 = 1CH which indicates RETRY /DENY 
Z2 = Destination address of response 

Z3 = Source address of response (40H,48H,50H) 
Z4 = Retry delay 


Z1 - Z4 



10 The number "n" is limited by the MDB maximum message length of 36 bytes. 
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Sub-Command used by the VMC for an FTL RETRY / DENY. 



FB + Y1 - Y3 



The VMC is retrying, denying, or aborting a data transfer to/from the USD whose destination 
address will always 

be (40H, 48H, 50H). Note that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (40H,48H,50H) 
Y2 = Source address of command 
Y3 = Retry delay 



Sub-Command used by the VMC for an FTL SEND BLOCK. 



Sub-Cmd 


Meaning or interpretation 


FC + Y1 - Y33 


The VMC is sending data to the USD whose destination address will always be (40H, 48H, 
50H). Note that all 

FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (40H,48H,50H) 
Y2 = Block # 

Y3 - Y33 = Data (maximum of 31 bytes) 



Sub-Command used by the VMC for an FTL OK TO SEND. The Z1 to Z33 
response can be either immediate or delayed (POLLed). 



Sub-Cmd 


Meaning or interpretation 


FD + Y1 - Y2 

USD Response 

Z1 - Z34 


The VMC is requesting to receive data from the USD whose destination address will always be 
(40H, 48H, 50H). Note that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (40H,48H,50H) 
Y2 = Source address of command 

Meaning or Interpretation 

Z1 = 1 DH which indicates SEND BLOCK 
Z2 = Destination address of data 
Z3 = Source address of data 

Z4 - Z34 = Data (maximum of 31 bytes) 



Sub-Command used by the VMC for an FTL REQ TO SEND. The Z1 - Zn 
response can be either immediate or delayed (POLLed). 



Sub-Cmd 




FE + Y1 - Y5 


The VMC is requesting to send data to the USD whose destination address will always be (40H, 
48H, 50H). 

Note that all FTL Commands / Responses are defined 
in Section 2.6. 
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Y1 


= Destination address of command (40H,48H,50H) 




Y2 


= Source address of command 




Y3 


= File ID 




Y4 


= Maximum length 




Y5 


= Control 


USD Response 


Meaning or Interpretation 


Z1 - Z34 


Z1 


= 1 EH which indicates OK TO SEND 




Z2 


= Destination address of response 


or 


Z3 


= Source address of response (40H,48H,50H) 


Z1 - Z4 


Z1 


or 

= 1 CH which indicates RETRY / DENY 




Z2 


= Destination address of response 




Z3 = 


Source address of response (40H.48H, 50H) 




Z4 = 


Retry delay 



Data sequence transmitted by the USD to the VMC after a diagnostic 
command 



USD Response 


Meaning or interpretation 


FF + Z1 - Zn = 


Diagnostic response. 



9.4 USD Power Requirements 

This section defines the maximum power requirements for a USD. 



USD peripherals may draw power from the MDB bus or from an integral power 
supply. In such cases where the USD will require power from the MDB bus, the 
current draw must remain within the following limits: 





Current draw 


Idle 


200 mA ( maximum continuous) 


Vending/Homing 


1 .75 A (for up to 1 seconds) 
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9.5 Examples - Mode 1/2/3 Sessions 

This section contains three examples of USD sessions in which each of the three 
modes of USD operation are demonstrated operation respectively. 



9.5.1 MODE ONE 

In this example session the VMC selects the item to vend and knows the vend price. The USD receives the vend command, attempts the 
vend, and reports if the attempted vend failed or was successful. 





=> 


43+02+01+03 


VMC requests to vend item from the 
USD. 






<ACK> 


USD acks vend request. 


<= 


=> 


42 


VMC polls the USD. 






<ACK> 


USD acks receipt of poll. 


<= 


=> 


42 


VMC polls the USD again . 






02 


USD responds: vend complete 


<= 


=> 


<ACK> 


VMC acks vend outcome. 
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9.5.2 MODE TWO 

In this example session the USD or the VMC can select items to vend but the 
USD may not be aware of the vend price of the item selected. If the USD needs 
the selected item price, it may request the item price from the VMC. The USD 
must then issue a VEND request, and wait for approval from the VMC before a 
vend is attempted. The VMC then approves or denies the requested vend and 
polls the USD for vend success or vend fail. 



VMC 1 MDB Data 


Explanation | USD 


=> 


42 


VMC polls the USD. 






05+02+06 


USD responds with pricing request for 
item in USD. 


<= 


=> 


<A^I\> 


VMC acks the USD price request. 




=> 


44+Ul +U^+UD+UU+1 4 
+FF+FF 


Using the Funds command the VMC 
sends a price of 20 coin factors for item 
in USD. 






<ACK> 


USD acks receipt of VMC price data. 


<= 


=> 


42 


VMC polls the USD. 






01+02+06+FF+FF 


USD responds with a request to vend 
item in USD at the VMC selected price. 


<= 


=> 


<ACK> 


VMC acks receipt of vend request. 




=> 


43 + 00 or 01 


VMC approves or denies vend request. 






<ACK> 


USD acks receipt of approval or denial. 


<= 


=> 


42 


VMC polls the USD. 






03+02+06+00+01 


USD responds: vend fail, sold out. 


<= 


=> 


<ACK> 


VMC acks vend outcome. 





• The FUNDS command can be used by USD's which do not have internal 
prices but need pricing information for display purposes or for other reasons 
that are not required to complete a transaction. 
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9.5.3 MODE THREE 

In this example session the USD selects the item to vend and is aware of the vend price of the item. The USD must issue a vend request and 
the VMC then approves or denies the requested vend. The VMC then polls the USD for vend success or vend fail. 



VMC 


MDB Data 


Explanation 


USD 


=> 


42 


VMC polls the USD. 






01 +03+02+00+1 E 


USD requests vend for item at in USD 
with price of 30 coin factors. 


<= 


=> 


<ACK> 


VMC acks the USD vend request. 




=> 


43+ 00 or 01 


VMC approves or denies vend request. 






<ACK> 


USD acks receipt of approval or denial. 


<= 


=> 


42 


VMC polls the USD. 






02 


USD responds: vend complete 


<= 


=> 


<ACK> 


VMC acks vend outcome. 
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9.6 Examples - Data Block Transfers 



This section contains two examples in which data blocks are transferred between 
the VMC and the USD and vice versa. 



9.6.1 Data Block Transfer from VMC to USD 



In this example the VMC wishes to send two data blocks to the USD. To do this, the VMC uses the expansion 02 command to advise the 
USD of it' s request to send data and also to identify the number of data blocks it wishes to send. In response, the USD uses a poll 09 to 
request the transmission of a data block with the block number enumerated as part of it's poll response. The VMC then uses a different 
expansion command (03) to send the data to the USD. 



VMC 


MDB Data 


Explanation 


lion 

USD 


=> 


47+02+02 


VMC issues a request to send two data 
blocks to the USD 








USD acks receipt of the request 


<= 


=> 


42 


VMC polls the USD 






09+00+01 


USD responds with a request to receive 
data block number 01 from the VMC 


<= 


=> 


<ACK> 


VMC acks receipt of block number 




=> 


47+03+01+21+22+23 


VMC transmits block number 01 
containing data: 21 , 22, and 23. 






<ACK> 


USD acks receipt of the data block 


<= 


=> 


42 


VMC polls the USD. 






09+00+02 


USD responds with a request to receive 
data block number 02 from the VMC. 


<= 


=> 


<ACK> 


VMC acks receipt of the block number. 




=> 


47+03+02+24+25+26 


VMC transmits block number 02 
containing data: 24, 25, and 26. 






<ACK> 


USD acks receipt of the data block 


<= 
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9.6.2 Data Block Transfer from USD to VMC 



In this example the USD wishes to send two data blocks to the VMC. To do this, the USD makes use of the Poll 09 command to inform the 
VMC of it's request to send data and also to identify the number of data blocks it wishes to send. In response, the VMC uses expansion 04 
command to request the transmission of a data block by the individual block number. The USD then uses the poll 09 response to send the 
data blocks to the VMC. 



1 f R H f*\ 

VMC 


MDB Data 




USD 


=> 


42 


VMC polls the USD 






09+01+02 


USD responds with a request to send 2 
data blocks to the VMC 


<= 


=> 


<ACK> 


VMC acks request to send data 




=> 


47+04+01 


VMC responds with a request to receive 
data block number 01 from the USD 






<ACK> 


USD acks receipt of block number 
request 


<= 


=> 


42 


VMC polls the USD 






09+02+01+55+56+57 


USD responds by transmitting block 
number 01 containing data 55, 56, and 
57. 


<= 


=> 


<ACK> 


VMC acks receipt of data 




=> 


47+04+02 


VMC responds with a request to receive 
data block number 02 from the USD 






<ACK> 


USD acks receipt of block number 
request 


<= 


=> 


42 


VMC polls the USD 






09+02+02+58+59+60 


USD responds by transmitting block 
number 02 containing data 58, 59, and 
60. 


<= 


=> 


<ACK> 


VMC acks receipt of data 
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Section 10 

Coin Hopper or Tube - Dispenser 
VMC/Peripheral Communication Specifications 

10.1 Introduction 



This section defines the communication bytes sent and received by a coin 
dispensing device, which may be in the form of a hopper or tube device. As 
defined in Section 2.3, the dispenser's address is 0101 "IxxxB (58H). 

Unless stated otherwise, all information is assumed to be in a binary format 

10.2 VMC Commands 



Command 

RESET 
SETUP 



DISPENSER STATUS 
status and 



Hex Code Description 

58H Command for dispenser to self-reset 

59H Request for dispenser setup. 

5AH Request for dispenser tube / hopper 

coin count. 



POLL 



5BH 



MANUAL DISPENSE 

dispensing. 

ENABLE 



DISPENSE* 5DH 



PAYOUT * 5EH 
dispensed. 



EXPANSION * 5FH 



Request for dispenser activity status. 
5CH Signifies coin types allowable for coin 

This command is followed by setup data. 

See command format section. 

Command to dispense coins. 

Followed by coin type or value to dispense. 

See command format section. 

Command to determine value of coins 

Followed by payout status or value poll. 
See command format section. 

Command to allow addition of features, File 
Transport Layer, and future enhancements. 
See command format section. 
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* NOTE: DISPENSE, PAYOUT, and EXPANSION commands are always 
followed by a "sub-command." 



MDB/ICP Version 3.0 



March 26, 2003 



173 



Multi-Drop Bus / Internal Communication Protocol 



10.3 VMC Command Format 



VMC Command Code VMC Data 

RESET 58H No data bytes 

This command is the vehicle that the VMC should use to tell the dispenser that it 
should return to its default operating mode and initialize internal hardware 
systems. With the exception of the ACK response, it should abort all 
communication until otherwise instructed by the VMC. 



The following initialization sequence is recommended. It should be used after "power up" or after issuing the 
Bus Reset (pulling the transmit line "active" for a minimum of 100 mS). 

RESET -58h 
POLL-5Bh 

To obtain "JUST RESET" response 

SETUP -59h 

To obtain dispenser level and configuration information 

EXPANSION IDENTIFICATION - 5F OOh 

To obtain additional dispenser information and options 

EXPANSION FEATURE ENABLE -5F 01 h 

To enable desired options 

DISPENSER STATUS -5Ah (Note 1) 

To obtain dispenser status / change information 

MANUAL DISPENSE ENABLE - 5Ch 

To enable and disable manual coin pay-out if desired 

No power above idle current can be drawn until after the first POLL following the 
RESET command. Also, the JUST RESET response to the POLL command 
must be delayed until any high current usage has been completed. 

The dispenser must hold its response of the DISPENSER status until a valid 
current reading from the sensor system is achieved. 
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VMC Command Code Dispenser Response Data 

SETUP 59H 26 bytes: Z1 - Z26 

Z1 = Dispenser Feature Level - 1 byte 

Indicates the feature level of the dispenser. This will distinguish the 
dispensers feature level to the VMC. Currently only level 1 is 
supported. 

Z2 - Z3 = Country / Currency Code - 2 bytes 

The packed BCD currency code of the dispenser is sent with the 
left most digit a 1 . See Appendix A1 for the latest version of the 
ISO 421 7 numeric currency code. For example, the code for the 
US dollar is 1 8 40H (Z2 = 1 8 and Z3 = 40) and for the Euro is 1 978 
(Z2 = 19 and Z3 = 78). 

Z4 = Coin Scaling Factor - 1 byte 

All dispensed coin values must be evenly divisible by this number. 
For example, this could be set to 05H for the USA nickel. 

Z5 = Decimal Places - 1 byte 

Indicates the number of decimal places on a credit display. For 
example, this could be set to 02H in the USA. 

Z6 = Application Maximum Response Time (seconds) - 1 byte 

The maximum length of time a dispenser will require to provide a 
response to any command from the VMC. The value reported here 
supercedes the dispenser's default NON-RESPONSE time defined 
in section 1 0.4 if the value reported here is greater. 

Z7 - Z8 = Bit set, if coin disabled by dispenser (i.e. switch). 

Z9 - Z1 = Bit set, if coin is self filling. 

Z1 1 - Z26 = Coin Type Credit - 1 6 bytes 

Indicates the value of coin types to 1 5. Values must be sent in 
ascending order. This number is the coin's monetary value divided 
by the coin scaling factor. Unused coin types are sent as 00H. 
Unsent coin types are assumed to be zero. It is not necessary to 
send all coin types. Coin type credits sent as FFH are assumed to 
be vend tokens. That is, their value is assumed to be worth one 
vend. 
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The byte position in the 16 byte string indicates the coin type(s). 
For example, the first byte sent would indicate the value of coin 
type 0, the second byte sent would indicate the value of coin type 1 , 
and so on. For example, the USA coin types may be; Coin type = 
nickel, Coin type 1 = dime, Coin type 2 = quarter, Coin type 3 = 
dollar. 
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VMC Command Code 

DISPENSER STATUS 5AH 



Dispenser Response Data 

34 bytes: Z1 - Z34 



Z1 - Z2 = Dispenser Full Status - 2 bytes 

Indicates status of coin tube / hopper for coin types to 15. 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 
b2 b1 bO 

Z1 Z2 

A bit is set to indicate a full dispenser. For example, bit 7 = set would 
indicate the dispenser for coin type 7 is full. 

Z3 - Z34 = Coin Count - 32 bytes 

Indicates the greatest number of coins that the dispenser "knows" 
definitely are present in the coin tube / hopper. A word (2bytes) 
position in the 32 byte string indicates the number of coins in a tube 
/ hopper for a particular coin type. For example, the first 2 bytes 
sent indicate the number of coins in a tube / hopper for coin type 0. 
Unsent bytes are assumed to be zero. For tube / hopper counts 
greater than 65535, counts should remain at 65535. 

NOTE: If a dispenser can detect a tube or hopper jam, defective tube or 
hopper sensor, or other malfunction, it will indicate the tube / hopper is "bad" by 
sending a tube / hopper full status and a count of zero for the malfunctioning coin 
type. 



VMC Command Code 



POLL 



5BH 



Dispenser Response Data 

32 bytes: Z1 - Z32 



Z1 - Z32 = Dispenser Activity - 32 bytes 

Indicates the dispenser activity. If there is nothing to report, the 
dispenser should send only an ACK. Otherwise, the only valid 
responses are: 



Coins Dispensed: 



Z1 



y 

xxxx 



(10yzxxxx) 



z=1 for manual dispense 

z=0 to report a non manual (automatic) dispense 

y=1 For payout complete. 

The coin type dispensed (0 to 1 5) 
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Z2- Z3 
Z4-Z5 



The number of coins dispensed. 
The number of coins in the dispenser. 
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Status: 



(00000001) = 



(00000010) = 

(00000011) = 
(00000100) = 



(00000101) = 

(00000110) = 

(00000111) = 

(00001000) = 



(00001001) 
(00001010) 

(00001011) 



(00001100) 
(00001101) 
(00001110) 
(00001111) 



Escrow request 1 - An escrow lever activation 
has been detected. If a button is present and 
activated. 

Dispenser Payout Busy 2 - The dispenser is 
busy activating payout devices. 
Not Used 

Defective Dispenser Sensor 1 - The dispenser has 
detected one of the dispenser sensors behaving 
abnormally. 
Not Used 

Dispenser did not start 1 ■ 

Dispenser Jam 1 - A dispenser payout attempt 
has resulted in jammed condition. 

ROM checksum error 1 - The dispensers internal 
checksum does not match the calculated 
checksum. 
Not Used 
Not Used 

Dispenser was "Just Reset" 1 - The dispenser 
has detected a Reset condition and has 
returned to its power-on idle condition. 
Not Used 
Not Used 
Not Used 

Filled key pressed 1 - Tne VMC snould request 
a new DISPENSER STATUS. 



NOTES: The dispenser may send several of one type activity, up to 1 6 bytes 
total. This will permit zeroing counters such as inventory and status. 

1 Sent once each occurrence. 

2 Sent once each POLL 
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File Transport Layer POLLed responses: 

Note that all FTL responses are defined in Section 2.6. For the coin dispenser, the source address will always 
be the dispenser (58H) as defined in Section 2.3. 



Z1 



1B 



to 



REQ TO RCV The coin dispenser is requesting 

receive data from a device or VMC. 

Z2 = Destination address of response 

Z3 = Source address of response (58H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



1C RETRY/DENY 
device or 



1D SEND BLOCK 
data 



1E OK TO SEND 



1F REQ TO SEND 



The coin dispenser is requesting a 

VMC to retry or deny the last FTL command. 

Z2 = Destination address of response 
Z3 = Source address of response (58H) 
Z4 = Retry delay 

The coin dispenser is sending a block of 

(maximum of 31 bytes) to a device or VMC. 

Z2 = Destination address of data 
Z3 = Block # 

Z4-Z34 = Data (maximum of 31 bytes) 

The coin dispenser is indicating that it 
is OK for a device or VMC to send it data. 

Z2 = Destination address of response 
Z3 = Source address of response (58H) 

The coin dispenser is requesting to 
send data to a device or VMC. 

Z2 = Destination address of response 

Z3 = Source address of response (58H) 

Z4 = File ID 

Z5 = Maximum length 

Z6 = Control 



MDB/ICP Version 3.0 



March 26, 2003 



180 



Multi-Drop Bus / Internal Communication Protocol 



MDB/ICP Version 3.0 March 26, 2003 



Multi-Drop Bus / Internal Communication Protocol 




VMC Command Code VMC Data 

MANUAL DISPENSE 5CH 2 bytes: Y1 - Y2 

ENABLE 

Y1 - Y2 = Manual Dispense Enable - 2 bytes 

b15 b14 b13 b12 b11 b10 b9 b8 | b7 b6 b5 b4 b3 b2 b1 bO 
Y1 Y2 

A bit is set to indicate dispense enable. For example, bit 2 is set to enable 
dispensing of coin type 2. This command enables/disables manual dispensing 
using optional inventory switches. All manual dispensing switches are 
automatically disabled upon reset. 



VMC Command Code Sub-command VMC Data 

DISPENSE COINS 5DH 00H 3 bytes: Y1 - Y3 

b7 b6 b5 b4 b3 b2 b1 bO 
Y1 

Bits b3, b2, b1 , bO indicate coin type to be dispensed. Valid codes are OH to FH 
to indicate coin types to 1 5. 

Bits b7, b6, b5, b4 = 



Y2 - Y3 = Number of coins to be dispensed of coin type defined in Yl 



There is no defined limit on how long the actual dispense takes 
since the command allows for up to 65535 coins to be paid out. The 
payout cycle begins when the dispenser ACKs the VMC's 
DISPENSE (5DH) command. This cycle typically lasts a minimum 
of 1 00 mS and ends when the dispenser stops dispensing the 
desired number of coins. VMCs should monitor the Dispenser 
Payout Busy and Dispenser Activity response to the POLL (5B) 
command to determine when the entire payout cycle is completed. 



VMC Command Code Sub-command VMC Data 

DISPENSE VALUE 5DH 01 H 2bytes:Y1,Y2 



Y1 - Y2 = Value of coins to be paid out. 
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Yl and Y2 are defined as the value of coins and this value is expressed as the number of 
coin scaling factors that would sum to the value. For example, in a USA system using a 
scaling factor of 05, if the change to be paid out is 75 cents, then Yl will equal fifteen. 
That is, the sum of fifteen nickels equal 75 cents. The coin dispenser will determine 
which actual denominations of coins will be paid out. In the 75 cent example, the coins 
may be 3 quarters; or, 7 dimes & 1 nickel; or, 2 quarters & 2 dimes & 1 nickel, etc. The 
actual coins dispensed and if the dispense is finished can be acquired via the PAYOUT 
STATUS (5E, 00) and PAYOUT VALUE POLL (5E, 01). 
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VMC Command Code Sub-command VMC Data Dispenser Response 



PAYOUT 
STATUS 



5E 00H 



None 32 bytes: Z1 -Z32 



Z1 - Z32 = Number of each coin type paid out - 32 bytes (2 bytes per coin 
type). 

This is the dispenser's response to the last VMC DISPENSE 
VALUE command (5DH sub command 01 H). Bytes are sent in 
ascending order of coin types. A bytes position in the string 
indicates the coin type. That is, bytes one and two are the number 
of coins for coin type 1 , bytes three and four are the number of 
coins for coin type two, and so on. Unsent bytes above the coin 
types dispensed are assumed to be zero. 

The dispenser clears payout data after an ACK response from the 
VMC. 



The VMC should compare the value of the coins paid out to the 
(5DH) DISPENSE VALUE command's Y2 -Y3. 

NOTES: 1) If the dispenser's payout is busy it will respond to the 
PAYOUT STATUS command with an ACK only. 

2) If no coins have been paid out, at least one zero valued data 
byte must be sent. 

3) There is no defined limit on how long the actual payout 
takes. See dispense command (5DH) for further details 



VMC Command Code Sub-command VMC Data Dispenser 
Response Data 

PAYOUT VALUE 5EH 01 H None 2bytes:Z1-Z2 

POLL 

Z1 - Z2 = Dispenser Payout Activity - 2 bytes 



An interval value (scaled) which indicates the amount of paid 
out change since the previous PAYOUT VALUE POLL (or 
between the initial DISPENSE VALUE command (5DH sub 
command 01 H) and the first PAYOUT VALUE POLL). 
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A 00H response indicates no coins were paid out since the 
previous PAYOUT VALUE POLL (or the initial DISPENSE 
VALUE command (5DH sub command 01 H)). 

An ACK only indicates that the change payout is finished. This should be followed by the 
PAYOUT STATUS command (5EH-00H) to obtain the complete payout data. 

NOTE: The initial intent of this command is to determine the amount of change 
paid out so that the credit display can be decremented as coins are dispensed. 
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VMC Command Code Sub-Command Dispenser Response Data 



EXPANSION 5FH 00H 33 bytes: Z1 - Z33 

COMMAND IDENTIFICATION 



Z1 - Z3 = 



Z4- Z15 = 



Z1 6 - Z27 = 



Z28 - Z29 = 
Z30 - Z33 = 



Manufacturer Code - 3 bytes 

Identification code for the equipment supplier. Sent as ASCII 
characters. Currently defined codes are listed in the EVA 
document entitled "European Vending Association Data 
Transfer Standard' (EVA-DTS), the Audit Data Lists section, sub- 
section 2, "Manufacturer Codes". 

Serial Number - 12 bytes 

Factory assigned serial number. All bytes must be sent as ASCII 
characters, zeros (30H) and blanks (20H) are acceptable. 

Model Number - 12 bytes 

Manufacturer assigned model number. All bytes must be sent as 
ASCII characters, zeros (30H) and blanks (20H) are acceptable. 

Software Version - 2 bytes 

Current software version. Must be sent in packed BCD. 
Optional Features - 4 bytes 

Each of the 32 bits indicate an optional features availability. If the 
bit is set the feature is available. Bits should be sent in descending 
order, i.e. bit 31 is sent first and bit is sent last. Currently defined 
options are: 

BO - File Transport Layer (FTL) supported as defined in 



Section 2.6. 



B1 - B31 



Available for future use 



VMC Command 

EXPANSION 
COMMAND 



Code Sub-Command 

5FH 01 H 
FEATURE ENABLE 



VMC Data 

4 bytes: Y1 - Y4 



MDB/ICP Version 3.0 



March 26, 2003 



186 



Multi-Drop Bus / Internal Communication Protocol 




This command is used to enable each of the optional features defined in Z30-Z33 
above. To enable a feature a bit is set to one. All optional features are 
disabled after reset. 
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VMC Command 

EXPANSION 
COMMAND 



Code Sub-command VMC Data Dispenser Response 

5FH FAH Y1-Y5 Z1 - Zn (immediate or 
FTL REQ TO RCV POLLed) 



The VMC is requesting to receive data from the dispenser whose destination address will always be (58H). 
Note that all FTL Commands / Responses are defined in Section 2.6. 



Y1 = Destination address of command (58H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Block # 

Z4 - Z34 = Data (maximum of 31 bytes) 

or 

Z1 = 1CH which indicates RETRY/ DENY 

Z2 = Destination address of response 

Z3 = Source address of response (58H) 

Z4 = Retry delay 



VMC Command Code Sub-command VMC Data Dispenser Response 

EXPANSION * 5FH FBH Y1-Y3 None 

COMMAND FTL RETRY /DENY 

The VMC is retrying, denying, or aborting a data transfer to/from the dispenser whose destination address will 
always be (58H). Note that all FTL Commands / Responses are defined in Section 2.6. 



Y1 = Destination address of command (58H) 

Y2 = Source address of command 

Y3 = Retry delay 
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VMC Command Code Sub-command VMC Data Dispenser Response 

EXPANSION 5FH FCH Y1-Y33 None 

COMMAND FTL SEND BLOCK 

The VMC is sending data to the dispenser whose destination address will always be (58H). Note that all FTL 
Commands / Responses are defined in Section 2.6. 



Y1 = Destination address of command & data (58H) 

Y2 = Block # 

Y3 - Y33 = Data (maximum of 31 bytes) 



VMC Command Code Sub-command VMC Data Dispenser Response 

EXPANSION ~~ 5FH FDH Y1-Y2 Z1 -Z34 (immediate or 

COMMAND FTL OK TO SEND POLLed) 

The VMC is indicating that it is OK for the dispenser to transfer data. The destination address will always be 
the dispenser (58H). Note that all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (58H) 

Y2 = Source address of command 

Z1 = 1 DH which indicates SEND BLOCK 

Z2 = Destination address of data 

Z3 = Source address of data 

Z4 - Z34 = Data (maximum of 31 bytes) 
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VMC Command Code Sub-command VMC Data Dispenser Response 



EXPANSION 5FH FEH Y1-Y5 Z1 (immediate or 
COMMAND FTL REQ TO SEND POLLed) 



The VMC is requesting to send data to the dispenser whose destination address will always be (58H). Note that 
all FTL Commands / Responses are defined in Section 2.6. 

Y1 = Destination address of command (58H) 

Y2 = Source address of command 

Y3 = File ID 

Y4 = Maximum length 

Y5 = Control 

Z1 = 1EH which indicates OK TO SEND 

Z2 = Destination address of response 

Z3 = Source address of response (58H) 

or 

Z1 = 1CH which indicates RETRY /DENY 

Z2 = Destination address of response 

Z3 = Source address of response (58H) 

Z4 = Retry delay 



VMC Command Code Sub-command VMC Data Dispenser Response 

EXPANSION 5FH FFH Y1-Yn Z1-Zn 

COMMAND DIAGNOSTICS 



Y1 - Yn = Device manufacturer specific instruction for implementing various 
manufacturing or test modes. Y1 - Yn implies that any number of 
bytes can be used for the VMC data to the peripheral. 

Z1 - Zn = Device manufacturer specific responses after receiving 

manufacturing or test instructions. Z1 - Zn implies that any number 
of bytes can be used for the Dispenser response data from the 
peripheral. 
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10.4 Dispenser Non-Response Time 

The default maximum non-response time for the dispenser is 5 seconds. This is 
the maximum time for which a dispenser will not respond to a command or a 
POLL with ACK, NAK or a message. The "Application Maximum Response 
Time" reported in byte Z6 of the SETUP (1 0.3) supersedes this default value if Z6 
is greater. 

10.5 Dispenser Power Requirements 



The current draw for any dispenser must fall within the following limits. All 
measurements are at the minimum VMC voltage output. 

Idle mode = 200 mA. (max.) continuous 

Coin payout = 2.5 A. (max.) for up to 15 seconds per coin dispensed. This is the 
maximum for all dispensers operating simultaneously in this unit. 
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Appendix 1 

Currency Codes 
A1.1 Information 



The following Tables of Codes for the Representation of Currencies and Funds are 

provided by the Secretariat of ISO 421 7 MA. It is provided here to be used for the MDB 
currency code information sent between the credit peripherals and the VMC. 

Table A.1 Currency and Funds Code List (English alphabetical order by 

entity) 

Table A.2 Funds Codes Registered with the Maintenance Agency 
Table A.3 Codes for Historic Denominations of Currencies and Funds 



A1.2 MDB/ICP Use 



As stated in the individual credit device sections, the two byte, packed BCD country / currency code of the coin changer, bill validator, and card 
reader devices can be sent in two different forms depending on the value of the left most BCD digit . 



If the left most digit is a 0, the International Telephone Code is used to indicate the country that the reader is set -up for. 



For example, the USA telephone code is 001 which translates into the 
MDB code as OOOlh (Zx =00h and Zy =01h). 



If the left most digit is a 1 , the latest version of the ISO 421 7 numeric currency code is 
used as listed in this Appendix. 

For example, the code for the US dollar is 840 which translates into the 
MDB code as 18 40h (Zx = 18h and Zy = 40h). 

The code for the Euro is 978 which translates into the MDB code 
as 1978h (Zx = 19h and Zy = 78 h). 

FFFFh should be used if the country code in unknown (Zx = FFh and Zy = FFh). 

Note that for level 3 cashless readers, it is mandatory to use thejhe ISO 421 7 numeric 
currency code. 
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Table A.1 Currency and Funds Code List (English alphabetical 
order by entity) 



ENTITY Currency Code Decimal 

Alphabetic Numeric Position 



AFGHANISTAN 


Afghani 


AFA 


004 


2 


ALBANIA 


Lek 


ALL 


008 


2 


ALGERIA 


Algerian Dinar 


DZD 


012 


2 


AMERICAN SAMOA 


US Dollar 


USD 


840 


2 


ANDORRA 


Spanish Peseta 


ESP 


724 


() 




French Franc 


FRF 


250 


2 




Andorran Peseta 


ADP 


020 





ANGOLA 


New Kwanza 


AON 


024 


2 




Kwanza Reajustado 


AOR 


982 


2 


ANGUTLLA 


East CarihHean 

J — (Clt>l v til 1 1 ' I til 1 

Dollar 


XCD 


951 


2 


ANTARCTICA 


No universal 
currency 








ANTIGUA AND 


East Caribbean 


XCD 


951 


2 


BARBUDA 


Dollar 








ARGENTINA 


Argentine Peso 


ARS 


032 


2 


ARMENIA 


Armenian Dram 


AMD 


051 


2 


ARUBA 


Aruban Guilder 


AWG 


533 


2 


AUSTRALIA 


Australian Dollar 


AUD 


036 


2 


AUSTRIA 


Schilling 


ATS 


040 


2 


AZERBAIJAN 


Azerbaijanian Manat 


AZM 


031 


2 


BAHAMAS 


Bahamian Dollar 


BSD 


044 


2 


BAHRAIN 


Bahraini Dinar 


BHD 


048 


3 


BANGLADESH 


Taka 


BDT 


050 


2 


BARBADOS 


Barbados Dollar 


BBD 


052 


2 


BELARUS 


Belarussian Ruble 


BYB 


112 







Belarussian Ruble 


BYR 


974 





BELGIUM 


Belgian Franc 


BEF 


056 





BELIZE 


Belize Dollar 


BZD 


084 


2 


BENIN 


CFA Franc BCEAO+ 


XOF 


952 





BERMUDA 


Bermudian Dollar 
(customarily known 
as Bermuda Dollar) 


BMD 


060 


2 


BHUTAN 


Indian Rupee 


INR 


356 


2 




Ngultrum 


BTN 


064 


2 



+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
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Table A. 1 (Continued) 



ENTITY 



Currency 



Alphabetic 



Code 

Numeric Position 



Decimal 



BOLIVIA 

BOSNIA & HERZEGOVINA 
BOTSWANA 
BOUVET ISLAND 
BRAZIL 

BRITISH INDIAN 
OCEAN TERRITORY 
BRUNEI DARUSSALAM 
BULGARIA 

BURKINA FASO 

BURUNDI 

CAMBODIA 



Boliviano BOB 

Mvdol* BOV 

Convertible Marks BAM 

Pula BWP 

Norwegian Krone NOK 

Brazilian Real BRL 

US Dollar USD 

Brunei Dollar BND 

Lev BGL 

Bulgarian LEV BGN 

CFA Franc BCEAO+ XOF 

Burundi Franc BIF 

Riel KHR 



068 
984 
977 
072 
578 
986 
840 

096 
100 
975 
952 
108 
116 



2 
2 
2 
2 
2 
2 
2 

2 
2 
2 


2 



CAMEROON 
CANADA 
CAPE VERDE 
CAYMAN ISLANDS 

CENTRAL AFRICAN 
REPUBLIC 
CHAD 
CHILE 



CHINA 

CHRISTMAS ISLAND 
COCOS (KEELING) 
ISLANDS 
COLOMBIA 
COMOROS 



CFA Franc BEAC# XAF 

Canadian Dollar CAD 

Cape Verde Escudo CVE 

Cayman Islands KYD 
Dollar 

CFA Franc BEAC# XAF 

CFA Franc BEAC# XAF 

Chilean Peso CLP 

Unidades de CLF 
fomento* 

Yuan Renminbi CNY 

Australian Dollar AUD 

Australian Dollar AUD 

Colombian Peso COP 

Comoro Franc KMF 



950 
124 
132 
136 

950 

950 
152 
990 

156 
036 
036 

170 
174 





2 
2 
2 







2 
2 
2 

2 




+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
lAfrique de l'Ouest. 

# CFA Franc BEAC; Responsible authority: Banque des Etats de l'Afrique 
Centrale. 



Funds code [See table A.2(E) for definitions of funds types]. 
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ENTITYCurrency 



Code Decimal 

Alphabetic Numeric 



Position 



CONGO 


CFA Franc BEAC# 


XAF 


950 





CONGO, THE DEMOCRATIC 


Franc Congolais 


CDF 


976 


2 


REPUBLIC OF 










COOK ISLANDS 


New Zealand Dollar 


NZD 


554 


2 


COSTA RICA 


Costa Rican Colon 


CRC 


188 


2 


COTEDTVOIRE 


CFA Franc BCEAO+ 


XOF 


952 





CROATIA 


Kuna 


HRK 


191 


2 


CUBA 


Cuban Peso 


CUP 


192 


2 


CYPRUS 


Cyprus Pound 


CYP 


196 


2 


CZECH REPUBLIC 


Czech Koruna 


CZK 


203 


2 


DENMARK 


Danish Krone 


DKK 


208 


2 


DJIBOUTI 


Djibouti Franc 


DJF 


262 





DOMINICA 


East Caribbean 


XCD 


951 


2 




Dollar 








DOMINICAN REPUBLIC 


Dominican Peso 


DOP 


214 


2 


EAST TIMOR 


Timor Escudo 


TPE 


626 







Rupiah 


IDR 


360 


2 


ECUADOR 


US Dollar 


ESD 


840 


2 


EGYPT 


Egyptian Pound 


EGP 


818 


2 


EL SALVADOR 


El Salvador Colon 


SVC 


222 


2 


EQUATORIAL GUINEA 


CFA Franc BEAC# 


XAF 


950 





ESTONIA 


Kroon 


EEK 


233 


2 


ERITREA 


Nakfa 


ERN 


232 


2 


ETHIOPIA 


Ethiopian Birr 


ETB 


230 


2 


FAEROE ISLANDS 


Danish Krone 


DKK 


208 


2 


FALKLAND ISLANDS 


Falkland Islands 








(MALVTNAS) 


Pound 


FKP 


238 


2 



# CFA Franc BEAC; Responsible authority: Banque des Etats de l'Afrique 
Centrale. 

+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
l'Afrique cfe l'Ouest. 

* Funds code [see Table A.2 (E) for definitions of funds types]. 
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Table A. 1 (Continued) 



ENTITYCurrency 



Code Decimal 

Alphabetic Numeric 



Position 



T7TTT 

rlJl 


Fiji Dollar 


r JJJ 


0/10 
Z4Z 


z 


T7T1VTT A NTH 


Markka 


rllvl 


0/1 £ 
Z40 


z 




French Franc 


rKr 


OCA 


z 


T7T> TTM/^T T PTTT A "NT A 

FRENCH uUlANA 


I ' 1 T ■ 

trench Franc 


T7T"> T7 


OCA 

z5U 


z 


M<bJN(_H PObYJNbSlA 


CFP franc 


XPt 


953 


(J 


T7DT7MPTT O/'M IT I IT~7r>\.T 

rKbJNCH bOUlHbRJN 


rrcncri Franc 


TTT» T7 


OCA 

z5U 


z 


1 bRKi 1 OKlhb 










UAdUiN 


LrA rranc ribAUff 


VAC 

AAr 


OCA 


A 

u 


P AA /ID T A 


Dalasi 


r^\/iP\ 


ota 
Z/U 


z 




bari 




no 1 
9ol 


z 


UhKJvl AN Y 


Deutsche Mark 


DbM 


Z/O 


z 


PTJ A XT A 


bedi 




ooo 
ZOO 


z 


PJDD AT TAD 

GIB KALI ak 


Gibraltar Pound 


ulr 


ono 

zyz 


Z 


Z" 1 T> T~? T~7 T~7 

uRbbCb 


Drachma 




OA A 

3(J(J 


z 


UKbbN b AN D 


Danish Krone 


DK.K. 


OAO 

zUo 


z 


LrKniNAJJA 


East Caribbean 


ALU 




z 




Dollar 








GUADEbOUPE 


French Franc 


FRF 


250 


2 


GUAM 


US Dollar 


USD 


840 


2 


GUATEMAbA 


Quetzal 


GTQ 


320 


2 


GUINEA 


Guinea Franc 


GNF 


324 





GUINEA-BISSAU 


Guinea-Bissau Peso 


GWP 


624 


2 




CFA Franc BCEAO+ 


XOF 


952 





GUYANA 


Guyana Dollar 


GYD 


328 


2 


HAITI 


Gourde 


HTG 


332 


2 




US Dollar 


USD 


840 


2 


HEARD AND 


Australian Dollar 


AUD 


036 


2 


MCDONALD ISLANDS 










HONDURAS 


bempira 


HNb 


340 


2 



# CFA Franc BEAC; Responsible authority: Banque des Etats de l'Afrique 
Centrale. 

+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
l'Afrique de l'Ouest. 
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Table A. 1 (Continued) 



ENTITYCurrency 



Code Decimal 

Alphabetic Nume ric 



Point 



HONG KONG 
HUNGARY 
ICELAND 
INDIA 
INDONESIA 
INTERNATIONAL 
MONETARY FUND 
(IMF)** 

IRAN (ISLAMIC 
REPUBLIC OF) 
IRAQ 
IRELAND 
ISRAEL 
nALY 
JAMAICA 
JAPAN 
JORDAN 
KAZAKHSTAN 
KENYA 
KIRIBATI 

KOREA, DEMOCRATIC 
PEOPLE'S REPUBLIC OF 
KOREA, REPUBLIC OF 



Hong Kong Dollar 
Forint 

Iceland Krona 
Indian Rupee 
Rupiah 
SDR 



Iranian Rial 

Iraqi Dinar 
Irish Pound 
New Israeli Sheqel* 
Italian Lira 
Jamaican Dollar 
Yen 

Jordanian Dinar 
Tenge 

Kenyan Shilling 
Australian Dollar 
North Korean Won 

Won 



HKD 

HUF 

ISK 

INR 

IDR 

XDR 



IRR 

IQD 

IEP 

ILS 

ITL 

JMD 

JPY 

JOD 

KZT 

KES 

AUD 

KPW 

KRW 



344 
348 
352 
356 
360 
960 



364 

368 
372 
376 
380 
388 
392 
400 
398 
404 
036 
408 

410 



2 
2 
2 
2 
2 

NA. 



3 
2 
2 

2 

3 
2 
2 
2 
2 



* Currency name was effective 4th September 1985 

** This entry is not derived fron ISO 3166, but is included here in alphabetic 
sequence for convenience. 
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Table A. 1 (Continued) 



ENTITY 



Currency 



Code Decimal 
Alphabetic Numeric Point 



KUWAIT 
KYRGYZSTAN 
LAO PEOPLE'S 
DEMOCRATIC 
REPUBLIC 
LATVIA 
LEBANON 
LESOTHO 



LIBERIA 
LIBYAN ARAB 
JAMAHIRIYA 
LIECHTENSTEIN 
LITHUANIA 
LUXEMBOURG 
MACAU 

MACEDONIA, THE 
FORMER YUGOSLAV 
REPUBLIC OF 
MADAGASCAR 
MALAWI 
MALAYSIA 
MALDIVES 
MALI 
MALTA 

MARSHALL ISLANDS 

MARTINIQUE 

MAURITANIA 

MAURITIUS 

MEXICO 



MICRONESIA 
MOLDOVA, REPUBLIC OF 
MONACO 



Kuwaiti Dinar KWD 
Som KGS 
Kip LAK 



Latvian Lats LVL 

Lebanese Pound LBP 

Rand ZAR 

(financial Rand)* ZAL 

Loti LSL 

Liberian Dollar LRD 

Libyan Dinar LYD 

Swiss Franc CHF 

Lithuanian Litas LTL 

Luxembourg Franc LUF 

Pataca MOP 

Denar MKD 



Malagasy Franc MGF 

Kwacha MWK 

Malaysian Ringgit MYR 

Rufiyaa MVR 

CFA Franc BCEAO+ XOF 

Maltese Lira MTL 

US Dollar USD 

French Franc FRF 

Ouguiya MRO 

Mauritius Rupee MUR 

Mexican Peso MXN 

Mexican Unidad de MXV 
Inversion (UDI)* 

US Dollar USD 

Moldovan Leu MDL 

French Franc FRF 



414 
417 
418 



428 
422 
710 
991 
426 
430 
434 

756 
440 
442 
446 
807 



450 
454 
458 
462 
952 
470 
840 
250 
478 
480 
484 
979 

840 
498 
250 



3 
2 
2 



2 
2 
2 
2 
2 
2 
3 

2 
2 

2 
2 





2 
2 
2 

2 
2 
2 
2 
2 
2 



2 
2 
2 



* Funds code [ See table A.2(E) for definitions of funds types]. 
+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
lAfrique de l'Ouest. 
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ENTITY 



Currency 



Code Decimal 
Alphabetic Numeric Point 



MONGOLIA 


Tugrik 


MNT 


496 


2 


MONTSERRAT 


East Caribbean 
Dollar 


XCD 


951 


2 


MOROCCO 


Moroccan Dirham 


MAD 


504 


2 


MOZAMBIQUE 


Metical 


MZM 


508 


2 


MYANMAR 


Kyat 


MMK 


104 


2 


TVT A "iv Tin I A. 

NAMIBIA 


Rand 


ZAR 


710 


2 




TVT '1 ' r~"\ 11 ibib 

Namibia Dollar** 


NAD 


516 


2 


NAURU 


Australian Dollar 


AUD 


036 


2 


NEPAL 


Nepalese Rupee 


NPR 


524 


2 


NETHERLANDS 


Netherlands Guilder 


NLG 


528 


2 


NETHERLANDS 


Netherlands 


ANG 


532 


2 


ANTILLES 


Antillian Guilder 








\rpTT 7 A T rr\/^\ TT A 

NEW CALEDONIA 


CFP Franc 


XPF 


r\ c ~~y 

953 





NEW ZEALAND 


New Zealand Dollar 


NZD 


554 


2 


NICARAGUA 


Cordoba Oro 


NIO 


558 


2 


NIGER 


CFA Franc BCEAO+ 


XOF 


952 





NIGERIA 


Naira 


NGN 


566 


2 


NIUE 


New Zealand Dollar 


NZD 


554 


2 


NORFOLK ISLAND 


Australian Dollar 


AUD 


036 


2 


NORTHERN MARIANA 


US Dollar 


USD 


840 


2 


ISLANDS 










NORWAY 


Norwegian Krone 


NOK 


578 


2 


OMAN 


Rial Omani 


OMR 


512 


3 


PAKISTAN 


Pakistan Rupee 


PKR 


586 


2 


PALAU 


US Dollar 


USD 


840 


2 



+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
lAfrique de l'Ouest. 

# The lowest unit of recorded value for the Iraqi Dinar is the Dirham 
(1 Iraqi Dinar = 20 Dirhams). 



The Namibia Dollar becomes effective September 15th 1993 
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ENTITYCurrency 



Code Decimal 

Alphabetic Numeric Point 



PANAMA 


Balboa 


PAB 


590 


2 




US Dollar 


USD 


840 


2 


PAPUA NEW GUINEA 


Kina 


PGK 


598 


2 


PARAGUAY 


Guarani 


PYG 


600 





PERU 


Nuevo Sol 


PEN 


604 


2 


PHILIPPINES 


Philippine Peso 


PHP 


608 


2 


PITCAIRN 


New Zealand Dollar 


NZD 


554 


2 


POLAND 


Zloty 


PLN 


985 


2 


PORTUGAL 


Portuguese Escudo 


PTE 


620 





PUERTO RICO 


US Dollar 


USD 


840 


2 


QATAR 


Qatari Rial 


QAR 


634 


2 


REUNION 


French Franc 


FRF 


250 


2 


ROMANIA 


Leu 


ROL 


642 


2 


RUSSIAN FEDERATION 


Russian Ruble 


RUR 


810 


2 




Russian Ruble 


RUB 


643 


2 


RWANDA 


Rwanda Franc 


RWF 


646 





ST HELENA 


St Helena Pound 


SHP 


654 


2 


ST KITTS - NEVIS 


East Caribbean 
Dollar 


XCD 


951 


2 


SAINT LUCIA 


East Caribbean 
Dollar 


XCD 


951 


2 


ST PIERRE AND 


French Franc 


FRF 


250 


2 


MIQUELON 










SAINT VINCENT 


East Caribbean 


XCD 


951 


2 


AND THE 


Dollar 








GRENADINES 










SAMOA 


Tala 


WST 


882 


2 


SAN MARINO 


Italian Lira 


ITL 


380 





SAO TOME AND 


Dobra 


STD 


678 


2 


PRINCIPE 










SAUDI ARABIA 


Saudi Riyal 


SAR 


682 


2 
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ENTITY 



Currency 



Code Decimal 
Alphabetic Numeric Point 



SENEGAL 

SEYCHELLES 

SIERRA LEONE 

SINGAPORE 

SLOVAKIA 

SLOVENIA 

SOLOMON ISLANDS 

SOMALIA 
SOUTH AFRICA 
SPAIN 
SRI LANKA 
SUDAN 
SURINAME 
SVALBARD AND 
JAN MAYEN 
ISLANDS 
SWAZILAND 
SWEDEN 
SWITZERLAND 
SYRIAN ARAB 
REPUBLIC 
TAIWAN, PROVINCE 
OF CHINA 
TAJIKISTAN 



CFA Franc BCEAO+ 
Seychelles Rupee 
Leone 

Singapore Dollar 
Slovak Koruna 
Tolar 

Solomon Islands 
Dollar 

Somali Shilling 
Rand 

Spanish Peseta 
Sri Lanka Rupee 
Sudanese Dinar 
Surinam Guilder 
Norwegian Krone 



Lilangeni 
Swedish Krona 
Swiss Franc 
Syrian Pound 

New Taiwan Dollar 



Tajik Ruble 



XOF 

SCR 

SLL 

SGD 

SKK 

SIT 

SBD 

SOS 

ZAR 

ESP 

LKR 

SDD 

SRG 

NOK 



SZL 
SEK 
CHF 
SYP 

TWD 

TJR 



952 
690 
694 
702 
703 
705 
090 

706 
710 
724 
144 
736 
740 
578 



748 
752 
756 
760 

901 

762 





2 
2 
2 
2 
2 
2 

2 
2 

2 
2 
2 
2 



2 
2 
2 
2 



+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
lAfrique de l'Ouest. 



MDB/ICP Version 3.0 



March 26, 2003 



202 



Multi-Drop Bus / Internal Communication Protocol 



Table A. 1 (Continued) 



ENTITY 



Currency 



Code Decimal 
Alphabetic Numeric Point 



TANZANIA, UNITED 


Tanzanian Shilling 


TZS 


834 


2 


REPUBLIC OF 










Fill T A T T A X ■ ■ -v 

THAILAND 


Baht 


THB 


764 


2 


TOGO 


CFA Franc BCEAO+ 


XOF 


952 





TOKELAU 


New Zealand Dollar 


NZD 


554 


2 


TONGA 


Pa'anga 


TOP 


776 


2 


TRINIDAD AND 


Trinidad and Tobago 


TTD 


780 


2 


TOBAGO 


Dollar 








TUNISIA 


Tunisian Dinar 


TND 


788 


3 


TURKEY 


Turkish Lira 


TRL 


792 





TURKMENISTAN 


Manat 


TMM 


795 


2 


TURKS AND CAICOS 


US Dollar 


USD 


840 


2 


ISLANDS 










TUVALU 


Australian Dollar 


AUD 


036 


2 


UGANDA 


Uganda Shilling ++ 


UGX 


800 





UKRAINE 


Hryvnia 


UAH 


980 


2 


UNITED ARAB 


UAEDirham 


AED 


784 


2 


EMIRATES 










UNITED KINGDOM 


Pound Sterling 


GBP 


826 


2 


UNITED STATES 


US Dollar 


USD 


840 


2 




(Same day)* 


USS 


998 


2 




(Next day)* 


USN 


997 


2 


UNTIED STATES 


US Dollar 


USD 


840 


2 



MINOR OUTLAYING 
ISLANDS 



+ CFA Franc BCEAO; Responsible authority: Banque Centrale des Etats de 
lAfrique de l'Ouest. 

++ The Uganda Shilling was denominated as from 18 May 1987. 

* Funds code [ See table A.2(E) for definitions of funds types]. 
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ENTITY 



Currency 



Code Decimal 
Alphabetic Numeric Point 



URUGUAY 

UZBEKISTAN 

VANUATU 

VATICAN CITY STATE 

(HOLY SEE) 
VENEZUELA 
VIETNAM 
VIRGIN ISLANDS 

(BRITISH) 

VIRGIN ISLANDS (U.S.) 
WALLIS AND FUTUNA 
ISLANDS 

WESTERN SAHARA 

YEMEN 

YUGOSLAVIA 

ZAMBIA 

ZIMBABWE 



Peso Uruguayo UYU 

Uzbekistan Sum UZS 

Vatu VUV 

Italian Lira ITL 

Bolivar VEB 

Dong VND 

US Dollar USD 

US Dollar USD 

CFP Franc XPF 

Moroccan Dirham MAD 

Yemeni Rial YER 

New Dinar YUM 

Kwacha ZMK 

Zimbabwe Dollar ZWD 



858 
860 
548 
380 

862 
704 
840 

840 
953 

504 
886 
891 
894 
716 



2 
2 



2 
2 
2 

2 


2 
2 
2 
2 
2 
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ENTITYCurrency 



Code Decimal 

Alphabetic Numeric Position 



Entity not applicable 



Gold XAU 

Bond Markets Units 

European Composite XBA 
Unit (EURCO) 

European Monetary XBB 
Unit (E.M.U.-6)*** 

European Unit of XBC 

Account 9 

(E.U.A.-9) 

European Unit of XBD 
Account 17 
(E.UA.- 17) 



959 



955 



956 



957 



958 



NA. 



NA. 



NA. 



NA. 



N.A. 



Palladium 

Platinum 

Silver 



XPD 
XPT 
XAG 



964 
962 
961 



N.A. 
N.A. 
N.A. 



*** E.M.U.-6 is sometimes known as the European Currency Unit. This should not be confused 
with the settlement unit of the European Monetary Cooperation Fund (E.M.C.F.) which has 
the same name (see entry for European Monetary Cooperation Fund' in this table). 
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Table A. 1 (Continued) 



ENTITY 



Currency Code Decimal 

Alphabetic Numeric Position 



Entity not applicable 



Special settlement currencies 



UIC-Franc 
Gold-Franc 



XFU 
XFO 



Nil 
Nil 



N.A. 
N.A. 



Codes specifically 
reserved for testing 
purposes 



XTS 



963 



N.A. 



The codes assigned for XXX 
transactions where no 
currency is involved 
are: 



999 



N.A. 



euro* 



EUR* 



978 



On 1 January 1999, the euro will become the currency of those Member States of the European 
Union which adopt the single currency in accordance with the Treaty establishing the European 
Community. This code has been issued now so that technical preparations can be started. The 
code element "EU" has been reserved by the ISO 3166 Maintenance Agency for use within ISO 
4217 where "R" has been appended to make an acceptable mnemonic code. 
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CURRENCY Currency Fund Type 
AUTHORITY 



Code Decimal 
Alphabetic Numeric Position 



BOLIVIA 
CHILE 

MEXICO 

UNITED STATES US Dollar 



Mvdol 

Unidades de 
Fomento 



Same day 
Next day 



BOV 
CLF 



Mexican Unidad MXV 
de Inversion (UDI) 



USS 
USN 



984 
990 

979 



998 
997 



2 




2 
2 



Definitions of the fund types listed above 

BOV: For indexation purposes and denomination of certain finacial instruments (ex. treasury bills). The 
Mvdol is set daily by the Central Bank of Bolivia based upon the official USD/BOB rate. 

CLF: This development unit has been approved by the Chilean government for use in insurance transactions 
(with effect from 10 April 1980). 

ECV: A daily indexation mechanism set by the Ecuadorian Central Bank. The UVC is set according to the 
variation of the Consumer price Index (Urban), as compiled by the National Census and Statistics Institute 
(INEC). 

MXV : The UDI is an inflation adjusted mechanism set by the Central Bank of Mexico according to the 
variation in the Mexican Consumer Price Index. The value of the UDI is expressed in terms of Mexican 
Pesos per UDI. It is used to denominate mortgage loans, some bank deposits with maturities of 3 month or 
more and Government bonds (UDIBONOS). 

USN: "Next day" funds are immediately available for transfer in like funds, and subject to 

settlement, available the next business day for same day funds transfer or withdrawal in cash. 

USS: "Same day" funds are immediately available for transfer today or for withdrawal in cash, 
subject to the settlement of the transaction through the payment mechanism used. 

(USD designates the US Dollar, the currency designator when an accumlation of amounts contains more than 
one funds type.) 
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Table A.3 Codes for Historic Denomination of Currencies and 
Funds 



ENTITY 



Historic 
Currencies 



Code 



Numeric 



WD 



ALBANIA 

ANGOLA 

ARGENTINA 

1989/1990 
BELGIUM 

BOLIVIA 

BOSNIA & HERZEGOVINA 
BRAZIL 



BULGARIA 

1989/1990 

1989/1990 

BURMA# 

CHINA 

CROATIA 

CZECHOSLOVAKIA 
ECUADOR 



Old Lek 

Kwanza 

Peso Argentino 

Austral 

Peso 

Convertible Franc 
Financial Franc 

Peso 

Dinar 

Cruzeiro 
Cruzado 
New Cruzado 

Cruzeiro 
Cruzeiro Real 

Lev A/62 

Lev A/52 

N/A 

Peoples Bank 
Dollar 

Dinar 

KronaA/53 
Koruna 



CSU 



Sucre 

Unidad del Valor constante 
(UVQ* 



ALK * 

AOK 

ARP 
ARA 
ARY* 

BEC 
BEL 

BOP 

BAD 

BRB 
BRC 
BRN 

BRE 
BRR 

BGK* 

BGJ* 

BUK 

CNX* 
HRD 

CSK 

ECS 
ECV 



993 
992 



070 



076 
987 



200 

218 
983 



12/89 

03/91 

07/85 
01/92 



03/90 
03/90 

02/87 

09/97 

03/86 
02/89 
03/90 

08/93 
07/94 



02/90 

12/89 

01/95 

1989/1990 

03/93 

9/00 
9/00 



EQUATORIAL GUINEA 



Ekwele 



GQE 



226 



06/86 
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Ekwele 




EQE 



12/89 



* Non ISO code 

# Change in country name 
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Table 3 (Continued) 



ENTITY 



Historic 
Currencies 



Code 



Numeric 



WD 

01/99 



07/90 to 
09/90 

10/95 

02/86 
12/89 



1981 



EUROPEAN MONETARY European Currency 

COOPERATION FUND Unit (E.C.U) 
(EMCF)** 

GERMAN DEMOCRATIC Mark der DDR 
REPUBLIC 



GEORGIA 
GUINEA 



GUINEA BISSAU 

Between 1978- 



ICELAND 

1989/1990 

ISRAEL 

1989/1990 

Between 1978- 

LESOTHO 

LAO 

LATVIA 

LITHUANIA 

LUXEMBOURG 

MALDIVES 
MALI 

MALTA 
MEXICO 



Georgian Coupon 

Syli 
Syli 

Guinea Escudo 



Old Krona 

Old Shekel 
Pound 

Maloti 
Kip Pot Pol 
Latvian Ruble 
Talonas 

Convertible Franc 
Financial Franc 

Maldive Rupee 

Mali Franc 

Maltese Pound 
Mexican Peso 



XEU 



DDM 



GEK 

GNS 
GNE* 

GWE 



ISJ* 

ILR* 
ILP 

LSM 

LAJ* 

LVR 

LTT 

LUC 
LUL 

MVQ* 

MAF* 
MLF 

MTP 

MXP 



954 



278 



268 



989 
988 



446 



1981 

05/85 

12/89 

12/94 

07/93 

03/90 
03/90 

12/89 

12/89 
11/84 

06/83 

01/93 
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* Non ISO code 
Table 3 (Continued) 



ENTITY 



Historic 
Currencies 



Code 



Numeric 



WD 

1981 

10/90 

02/86 
07.91 

01/97 



MOZAMBIQUE 

Between 1978- 



NICARAGUA 
PERU 

1989/1990 

POLAND 

ROMANIA 

1989/1990 

SOUTH AFRICA 

SOUTHERN RHODESIA# 
Between 1978- 
1981 



SPAIN 



Between 1981- 



SUDAN 

UNION OF SOVIET 
SOCIALIST REPUBLICS* 

YEMEN, 

DEMOCRATIC OF 
UGANDA 

1989/1990 



Mozambique Escudo 

Cordoba 

Sol 
Inti 

Sol 

Zloty 
Leu A/52 

Financial Rand 
Rhodesian Dollar 

Spanish Peseta 

("A" Account) 

(convertible Peseta 
Accounts) 

Sudanese Pound 

Rouble 

Yemeni Dinar 



Uganda Shilling 
Old Shilling 



MZE 



NIC 

PES 
PEI 



PLZ 
ROK* 

ZAL 
RHD 

ESA 

ESB 

SDP 
SUR 

YDD 



UGS 
UGW* 



PEH 51 



616 



991 



03/95 



996 



995 



720 



1983 
12/94 

06/98 
12/90 

09/91 

05/87 
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UKRAINE 



Karbovanet 



UAK 



* Non ISO code 

# Change in country name. 
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Table 3 (Continued) 




ENTITY 



Historic 
Currencies 



Code 



Numeric 



WD 

12/89 
03/93 



URUGUAY 



VIETNAM 

1989/1990 

YUGOSLAVIA 



ZAIRE 



ZIMBABWE 

ENTITY AND 
CURRENCY NOT 
APPLICABLE 



Old Uruguay Peso 
Uruguayan Peso 
Old Dong 



New Yugoslavian 
Dinar 

Yugoslavian Dinar 

Zaire 
New Zaire 

Rhodesian Dollar 

RINET 
Funds Code 



UYN* 

UYP 

VNC* 

YUD 

YUN 

ZRZ 
ZRN 

ZWC* 

XRE 



890 



180 



N/A 



01/90 

11/95 

02/94 
06/99 

12/89 

11/99 



* Non ISO code 
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ANNEX 

INFORMATION TO BE PROVIDED BY THOSE MAKING APPLICATION FOR THE ISSUE 
OF NEW CODES, AMENDMENTS AND DELETIONS. 

Applications for additions or changes to the code lists are acceptable from any source. However, on 
order to ensure rapid processing by the Secretaries, the information required from applicants has been 
laid down as follows: 

(a) Name of entity 

(b) Name of currency 

(c) The institution responsible for the currency (name and place of 
operation). 

(d) Requirements: 

(1) Whether currency or funds code: if funds code, give 
definition and proposed use; 

(2) If new code, make proposal; 

(3) If revision, state existing code and make proposal; 

(4) If deletion, indicate code to be deleted; 

(e) Reason for application; 

(f) Evidence of support (currency code only); 

(g) Date of implementation (indicate if special conditions of urgency apply); 

(h) Application submitted by (name, address, telephone, telex numbers, etc, 
of applicant); 

(i) Date of application. 
Applications should be addressed to 

Miss A M Wadsworth Tel. (0181) 996 7466 National 

Secretariat for IS04217MA +44 1 8 1 996 7466 International 

BSI 

389 Chiswick High Road Fax (0181) 996 7466 National 

London +44 181 996 7466 International 

W4 4AL United Kingdom 
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Appendix 2 

Battery Operated Card Reader 
A2.1 Special Application 



The Battery Operated Card Reader described below is a special application of the 
MDB/ICP specification (non-standard) and is not sanctioned by NAMA. It is provided 
here to document an application that exists in use today. 



A2.2 Extension to MDB/ICP - Card Reader Using Standby Feature 

Some Vending machines use battery operated equipment. According to this feature, 
these machines and all devices used within these machines must provide a standby 
operating mode. 

During standby operation - necessary for saving battery power while the machine is not 
in use - all devices shall consume a minimum standby current. Any device is equipped 
with some hardware wake-up mechanism. Both standby current and wake-up 
mechanism is to be defined in the device related hardware specification. 

After wake-up, a device uses normal operating current, until a defined shutdown 
sequence is established and the device enters standby mode again. 

The following specification shows the extensions and procedures for a normal MDB/ICP 
card reader and VMC -controller necessary to do wake-up and shut down sequences. 
The hardware specification related to wake-up is a separate BDTA-document. To 
understand the following details, it is necessary to know, that a separate bi-directional 
wake-up pin is applied to the card-reader. Pulling the wake-up line (from the card-reader 
while a card is inserted), both card-reader and VMC will be brought to normal operation 
mode. 
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A2.3 Extension to MDB/ICP- SETUP Config Data 





Config 


VMC 


Columns 


Rows 


Display 


SETUP 


Data 


Feature 


on 


on 


Info 


(11 H) 


(00H) 


Level 


Display 


Display 






Y1 


Y2 


Y3 


Y4 


Y5 





Y1 : Configuration data. 

VMC is sending its configuration data to reader. 

Y2 : VMC Feature Level. 

Indicates the feature level of the VMC. The available feature levels are: 

01_ - The VMC is not capable or will not perform the advanced features as 
specified in Table 1 : COMMANDS & RESPONSES following Section 
7.3.2. The reader will not provide advanced information to the VMC, 
but can do the advanced features internally (transparently to the 
VMC). The reader has no revaluation capability. 

02 - The VMC is capable and willing to perform the advanced features as 

specified in Table 1: COMMANDS & RESPONSES following Section 
7.3.2. The reader will provide advanced information to the VMC (if 
possible) and will not do the advanced features internally. 

The VMC is able to support level 02, but also supports some or all of 
the optional features listed in the EXPANSION ID command (i.e., file 
transfer, 32 bit credit, multi-currency / language features, negative 
vend, and / or data entry). 

81 H: VMC is Level 01, but battery operated. 
82H: VMC is Level 02, but battery operated. 
83H: VMC is Level 03, but battery operated. 

Y3 : Columns on Display. The number of columns on the display. Set to 00H if 
the display is not available to the reader. 

Y4 : Rows on Display. 

The number of rows on the display. 

Y5 : Display Information - xxxxxyyy 
xxxxx = Unused 
yyy = Display type 

000 : Numbers, upper case letters, blank and decimal point. 

001 : Full ASCII 
010-111: Unassigned 
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Reader 


Reader 


Country / 


Country / 


Scale 


Decimal 


Application 


Miscellaneous 


Config 


Feature 


Currency 


Currency 


Factor 


Places 


Maximum 


Options 


Data 


Level 


Code 


Code 






Response 




(01 H) 




High 


Low 






Time 




Z1 


Z2 


Z3 


Z4 


Z5 


Z6 


Z7 


Z8 



Z1 : READER - Configuration data. 

Indicates the payment media reader is responding to a SETUP - 
Configuration data request from the VMC. 

Z2 : Reader Feature Level. 

Indicates the feature level of the reader. Currently feature levels are: 

The reader is not capable or will not perform the advanced features 
as specified in Table 1 : COMMANDS & RESPONSES following 
Section 7.3.2. The reader will not provide advanced information to 
the VMC, but can do the advanced features internally (transparently 
to the VMC). The reader has no revaluation capability. 

The reader is capable and willing to perform the advanced features 
as specified in Table 1 : COMMANDS & RESPONSES following 
Section 7.3.2. The reader will provide advanced information to the 
VMC (if possible) and will not do the advanced features internally. 
The reader is able to support level 02, but also supports some or all 
of the optional features listed in the EXPANSION ID command (i.e., 
file transfer, 32 bit credit, multi-currency / language features, 
negative vend, and / or data entry). 

This bit is additionally set, if the reader is capable to work in battery 
operation mode and should be compared with the VMC against its own 
working mode. This is also done from the reader against the VMCs 
request in Y2. 

Z3-Z4 : Country / Currency Code - packed BCD. 

The packed BCD country / currency code of the changer can be sent in two different forms depending on the value of the 
leftmost BCD digit. 



If the left most digit is a 0, the International Telephone Code is used to indicate the country that the changer is set-up for. 
For example, the USA code is 00 01H (Z3 = 00 and Z4 = 01). 



If the left most digit is a 1 , the latest version of the ISO 4217 numeric 
currency code is used (see Appendix A1 ). For example, the code for the 
US dollar is 1 8 40H (Z2 = 1 8 and Z3 = 40) and for the Euro is 1 978 (Z3 = 
1 9 and Z4 = 78). Use FFFFh if the country code in unknown. 
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For level 3 cashless readers, it is mandatory to use the ISO 421 7 numeric 
currency code (see Appendix A1 ). 

25 : Scale Factor. 

The multiplier used to scale all monetary values transferred between the 
VMC and the reader. 

Z6 : Decimal Places. 

The number of decimal places used to communicate monetary values 
between the VMC and the payment media reader. 

All pricing information sent between the VMC and the payment media 
reader is scaled using the scale factor and decimal places. This 
corresponds to: 

ActualPrice = PX-1CT Y 

where P is the scaled value send in the price bytes, and X is the scale 
factor, and Y is the number of decimal places. For example if there are 2 
decimal places and the scale factor is 5, then a scaled price of 7 will 
mean an actual of 0.35. 

Z7 : Application Maximum Response Time - seconds. 

The maximum length of time a reader will require to provide a response to 
any command from the VMC. The value reported here supercedes the 
payment reader's default NON-RESPONSE time defined in section 7.5 if 
the value reported here is greater. 

Z8 : Miscellaneous Options - xxxxyyyy 

xxxx: Unused (must be set to 0) 
yyyy: Option bits 

b0=0: The payment media reader is NOT capable of restoring funds 
to the user's payment media or account. Do not request 
refunds. 

b0=1 : The payment media reader is capable of restoring funds to the 

user's payment media or account. Refunds may be requested. 
b1 =0: The payment media reader is NOT multivend capable. 

Terminate session after each vend. 
b1 =1 : The payment media reader is multivend capable. Multiple items 

may be purchased within a single session. 
b2=0: The payment media reader does NOT have a display. 
b2=1 : The payment media reader does have its own display. 
b3=0: The payment media reader does NOT support the 

VEND/CASH SALE subcommand. 
b3=1 : The payment media reader does support the VEND/CASH 

SALE subcommand. 
b4-b7=0 Any future options must be covered by the EXPANSION 

COMMAND option bits. 
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Note: The following changes are the only changes to upgrade to battery operated readers: 

If a VMC is battery operated, it signals the card reader with the flag 80H to work in 
battery operation mode. Within byte Z2 the reader also sets the flag to 80H to signal 
standby feature capability. 

If only one of both is in standby capability, this results in an configuration error and the 
manufacturers should deal with handling of this condition. Assume that at least one 
device will not enter standby mode and therefore battery lifetime is dramatically 
reduced! 



A2.4 VMC-Reader Operation Sequences 



The VMC and the Reader should operate during battery mode in the following way: 

After wake-up, the VMC starts with the normal sequences: 

Reset 

Setup/Config 

MAX/MIN -price 

Identify 

Enable 

Poll 



During these sequences, the VMC has two possibilities to signal the Card- Reader, not 
to enter standby-mode again: 

Pulling the wake-up pin to low level 
Running poll sequences in continuos timing. 

If neither the wake-up pin is driven low, nor any command is further sent to the card 
reader, the reader enters standby state after its Application Maximum Response Time 
(normally defined to 5 sec in ICP, but sent in byte Z7 of status response) 



During card operation, the sequences continue normally with 
Begin Session 
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Vend Request 
Vend Accepted 
Vend Success 

Cancel Session/Session Complete 

Whenever a cancel session or session complete command is received, the reader 
should stop all internal work after a defined timeout period (Application Maximum 
Response Time) is finished after the last command sequence and after the wake-up pin 
is not pulled low. 

The VMC should stop polling after the cancel session or session complete command 
and additionally should no longer pull wake-up pin. 

If even the reader or the VMC may wish any further communication (i.e. for additionally 
trailing display messages or multi vend purposes or etc.) the reader can use any non 
idle answer to the poll command (i.e. the display message) whereas the VMC can 
continue polling or pulling the wake-up pin. 

Note that the wake-up pin may not be used from the reader to hold on operation, cause 
dynamic system consideration and of course holding more devices within the system in 
normal operation mode is not a good job. 

The reader should be in a power saving mode after this timeout period where power 
consumption is less than 10 uA. 

To allow the reader holding VMC operating, at least 5 poll have to be sent, after the 
cancel session or session complete. If any one of these polls is answered different with 
only a ACK, 5 polls have to be sent again. Note, that if a display message is sent, 
display time is added! 

If the reader entered standby state, and a new card is inserted, the procedure starts a 
again. 

Whenever during this next session, the reader should avoid all unnecessary work, i.e. 
display messages like „reader xyz, Software version 99.471 1" or „checking RAM" and 
so on should be avoided. While in battery operation, the user has inserted a card and is 
waiting for display of his fund, to continue with a vend and is not interested in service 
related messages. 
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A2.5 Session Example 



Card inserted. 



Reader pulls wake- 
up pin | 

Card reader runs 
Reset procedure 
and waits for VMC 
command 



VMC is entering 
normal operation - 
mode and running 
internal reset 
procedure 



VMC is pulling 
wake-up pin low 
and/or starting 
command 
sequence. 

This has to be done 
within the ICP 
default max. appl. 
Response time, in 
any other case the 
reader may enter 
standby mode 
again. 



Reader answers 
commands, checks 
card and monitors , 
wake- up line I 
If the reader will be 
enabled, begin 
session is sent 



Normal vend 
sequence will 
continue 



The reader waits for 
poll and starts 
standby timeout 
with it's own max. 
appl. Response 
time 



VMC displays credit 
and waits for user 
action 
If a vend is 
requested, vend 
request will be sent 
VMC signals vend 
success 

VMC sends session 
complete 
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VMC sends at least 
five polls and stops 
-pulling the wake-up 
line 



VMC displays 
messages for 10 
sec, and polls 
during these 10 sec. 
After the 1 sec 
have elapsed, 
additionally 5 poll 
will be sent 



The reader sends a 
display request witfcr 
a duration of 10 sec 
for a finishing thank- 
you message. 
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A2.6 Hardware Considerations 



Hardware Considerations 



Within this special battery operation, the pin 3 of MDB/ICP connector is used as a wake- 
up signal. Refer to special BDTA-hardware specification. 

To show an example of the timing for this pin, refer to the following diagram, which 
gives an example of all special timing problems related to more than one wake-up 
condition. 



TekaiiliB loks/s 



2 Acqs 



03 




2~* *^ i y JWA ^y^Y B * t Ti s ' ^ ^ p^** 11 ^^^^*^^' 



Style 
Vectors 



Intensity 



Readout 
Options 



D 



Graticule 
Full 



Format 
YT 



Display 
Style 



Vectors 



Dots 



Vector 
Accumulate 
100ms 



Dot 
Accumulate 
100ms 



Position A: mechanical switch on VMC is pulling pin 3 low (i.e. door switch) 

Position B: mechanical switch is released 

Position C: card reader has finished reset routines and pulls pin 3 low 

Position D: VMC has finished reset routines and pulls pin 3 low too. 



If a card is inserted first, pin 3 may be pulled low first at position B. 

If VMC is waked up via other means, maybe card reader is waked up at position D first. 

In any case, this is a good example to clarify different waveform conditions on pin 3. 
Please note that any device may release pin 3 after a short duration (<1 ms) cause pin 3 
should work as dynamically wake-up. Holding pin 3 permanently low may prevent other 
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devices from wake-up, i.e. after all devices ran into timeout and one is still holding pin 3, 
the other can no longer enter ready state (Note i.e. to door-switches etc.) 
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